WinRM in Mixed Domain Environments

Introduction

Windows Remoting works perfectly for same domain situations, and the set-up is relatively straight-forward. It's extremely powerful when it works, and offers a highly flexible way to securely execute commands remotely.

Problems arise however when trying to use WinRM in mixed domain environments, or where only one machine is on a domain. As I discovered, this requires some additional configuration steps outlined below.

Enabling Remoting

Enabling WinRM between computers on the same domain is straight forward by running the following command in an elevated Powershell console on the remote server. This enables WinRM and configures the firewall so that it can accept incoming commands.

Enable-PSRemoting

Once this is done, commands can then be executed against the machine remotely as follows:

Invoke-Command -ComputerName RM-SERVER -ScriptBlock {Get-Process}

This example will list processes on the remote machine named RM-SERVER using the Get-Process cmdlet.

Mixed Domain

Mixed domain environments require some additional configuration to get working. To do this, the following command needs to be executed on the remote server. This will allow the client server to authenticate from a different domain, or with an account local to the remote server.

New-Itemproperty -name LocalAccountTokenFilterPolicy 
-path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

With this configuration, it's now possible to authenticate and execute a command remotely with explicit credentials.

$credential = Get-Credential
Invoke-Command -ComputerName RM-SERVER -ScriptBlock {Get-Process} -Credential $credential

Or create the credential explicitly in script as shown below:

$securePassword = ConvertTo-SecureString "Password" -AsPlainText -force
$credential = New-Object System.Management.Automation.PsCredential("domain\username",$securePassword)
Invoke-Command -ComputerName RM-SERVER -ScriptBlock {Get-Process} -Credential $credential

Troubleshooting

WinRM Cannot Process the Request

Beware, I spent several hours on this. No matter what I did, I kept getting the following error. It turns out this was caused by the anti-virus software running on the remote server which had to be disabled.

Connecting to remote server failed with the following error message : 
WinRM cannot process the request. The following error occurred while using Kerberos authentication: 
There are currently no logon servers available to service the logon request.
Possible causes are:
  -The user name or password specified are invalid.
  -Kerberos is used when no authentication method and no user name are specified.
  -Kerberos accepts domain user names, but not local user names.
  -The Service Principal Name (SPN) for the remote computer name and port does not exist.
  -The client and remote computers are in different domains and there is no trust between the 
   two domains.
After checking for the above issues, try the following:
  -Check the Event Viewer for events related to authentication.
  -Change the authentication method; add the destination computer to the WinRM TrustedHosts 
   configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
   -For more information about WinRM configuration, run the following command: winrm help config. 
    For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (:) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionStateBroken

Trusted Hosts

The remote server can be configured to allow commands from only specific hosts. To set this, run the following in an elevated Powershell console on the remote server. By default, this is set to allow any host (*).

Set-item wsman:localhost\client\trustedhosts -value RM-Client1,RM-Client2

The line above configures the remote server to allow only commands from machines RM-Client1 and RM-Client2.

Firewall Configuration

WinRm requires port 5985 for http, or port 5986 for https. The Enable-PSRemoting cmdlet will auto-configure the Windows software firewall, but do ensure these ports are accessible across your network infrastructure.