Click here to Skip to main content
14,972,848 members
Articles / Programming Languages / PowerShell
Article
Posted 22 Jul 2011

Stats

28.5K views
2 bookmarked

WinRM in Mixed Domain Environments

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
22 Jul 2011CPOL2 min read
Windows Remoting works perfectly for same domain situations, but has some gotchas in mixed domain scenarios.

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.


License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

TheCodeKing
Architect
United Kingdom United Kingdom
Mike Carlisle - Technical Architect with over 20 years experience in a wide range of technologies.

@TheCodeKing

Comments and Discussions

 
QuestionCheck username format Pin
nutwiss14-Jun-19 1:51
Membernutwiss14-Jun-19 1:51 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.