PowerShell Remoting and the “Double-Hop” Problem

PowerShell Remoting and the “Double-Hop” Problem

Rate This
  • Comments 2

The “Double-Hop” Problem

 

Most of the newly added PowerShell cmdlets (“command-lets”) in Windows Server 2008 R2 allow easy remote execution by including the -Cluster parameter to indicate the target cluster.  However there are occasions when this capability cannot be used for different reasons, such as when a firewall is blocking the cluster management port, because a particular command (such as Add-ClusterDisk) does not have a -Cluster parameter, or when it has to be executed in a specific node.

 

For these cases PowerShell remoting can be a very useful feature which allows you run any PowerShell command from a remote machine.  The feature can be easily enabled by running Enable-PSRemoting, or also by domain group policy (note that you will also need to enable the “Windows Remote Management” firewall exception).  Then you can run Enter-PSSession <Target-Machine-Name> and you will be running cmdlets on the target machine.

 

Now you can remotely execute most cluster command like Add-ClusterDisk, but a problem arises when you try to execute command like Test-Cluster or New-Cluster.  Those commands not only execute on the target machine, but they actually need to perform operations on every node of a cluster (like verifying those machines registry settings, etc).  And that will fail because you are trying to make a remote operation from an environment which is already using a remote connection – this is known as the “double-hop” problem.

An Easy “Double-Hop” Solution

 

You can use CredSSP to delegate your credentials to the remote computer so every remote access from the remote machine will also work.  To enable this, you will need to run (from an elevated command prompt) the following command on the client machine:

 

Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>

 

That would allow you to use CredSSP as a client of the specified server.  Then, on the server machine(s), you need to run:

 

Enable-WSManCredSSP Server

 

That will allow incoming client CredSSP connections.  Now you can use PowerShell remoting from the client by creating a session specifically thru CredSSP:

 

New-PSSession <FQDN of the Server> -Authentication CredSSP -Credential <User> | Enter-PSSession

 

You will then be asked for the corresponding password and then you can start the remote session.  Now all those commands which call other nodes in your cluster will work.

 

Also instead of entering an interactive session with Enter-PSSession you can use the fan-out capabilities of PowerShell remoting for running the same command concurrently in several servers.  For more information about this, see the PowerShell remoting links below.

 

CredSSP Details

 

By default, when a user remotely logs on to a machine the logon session created is of the “remote” type, which in opposition of an “interactive” logon session doesn’t contains the user credentials.  Therefore this logon session allows operations on that particular machine but prevents opening a new remote session to another machine.  This is done for security purposes as it could be dangerous grant those credentials to a different machine which can be potentially compromised.

 

CredSSP is a Security Service Provider that allows you to authenticate in a remote machine creating a logon session that contains the user credentials.  It transfers the credentials securely over the network by first creating an encrypted session and then authenticating the machines by using the Negotiate protocol (which in turn will use Kerberos, NTLM, etc).  The particular authentication settings could be configured as indicated in the links below.  Therefore you should only enable CredSSP when you know that the target machine is not compromised as the plain text credentials will travel there.

 

Note that CredSSP is quite different of Kerberos delegation.  Without going into too much detail, Kerberos delegation works in a different way (by transferring the TGT instead of the actual credentials), and it is established by domain group policy which selects the associated information for the user credentials from AD.  Instead, CredSSP allow you to select a specific target with the specific credentials that you want to supply.

 

CredSSP can also be of great utility with other PowerShell environments or from applications that use SSPI.  It was initially created for Terminal Services, an operation that always require an extra (initial) hop.

 

Resources

 

PowerShell Remoting:

http://technet.microsoft.com/en-us/library/dd347706.aspx

http://technet.microsoft.com/en-us/library/dd315359.aspx

 

CredSSP:

http://msdn.microsoft.com/en-us/library/cc540483.aspx

http://technet.microsoft.com/en-us/library/cc749211(WS.10).aspx

 

 

Thanks,

Greg Maeso

Software Development Engineer

Clustering & High-Availability

Microsoft

 

Leave a Comment
  • Please add 4 and 8 and type the answer here:
  • Post
  • I try deploy Sharepoint WSP projects using PowerShell Remoting.

    See sharepoint.stackexchange.com/.../powershell-remoting-sharepoint-2010-error

    Solution is configure CredSSP for Sharepoint.

    But Microsoft says:

    Caution: Credential Security Service Provider (CredSSP) authentication, in which the user's credentials are passed to a remote computer to be authenticated, is designed for commands that require authentication on more than one resource, such as accessing a remote network share. This mechanism increases the security risk of the remote operation. If the remote computer is compromised, the credentials that are passed to it can be used to control the network session.

    Not recommended in production environments.

    Any suggestions for deploy using powershell remoting and sharepoint ?

  • Hello Symon,

    What if the CredSSP cmdlets don't work in the server because it's Windows XP or Windows 2003. Is there any way to perform those steps manually.

Page 1 of 1 (2 items)