PowerShell : A deep dive into remoting - part 7

In remoting when a user logged into a computer uses a command to execute a script block or another command on the remote machine that needs to access another machine remotely (a very common scenario is a SharePoint farm) where Kerberos is not enabled, you may encounter a problem called 'Double hop'. Double hop refers to the problem where the first server accessed via remoting tries to access the second server by default using the credentials the PowerShell process is running under. The problem arises because the credentials that the remote server uses to access the second server may not have the required permissions to perform the action.

The problem is related to the way Windows PowerShell delegates the credentials from Server1 to Server2. During delegation, any script or command executed on Server2 will be executed as the user that is defined by the credential. By default delegation can only traverse one hop, that means Server2 does not have the permission to delegate the credential to Server3 and it uses the credential of the PowerShell process to execute the script/ command on Server3 resulting in the problem. 

To get around this issue you need to use the CredSSP authentication mechanism in PowerShell.

Credential Security Service Provider (CredSSP) is a new security service provider that is available through the Security Support Provider Interface (SSPI) in Windows. CredSSP enables an application to delegate the user’s credentials from the client (by using the client-side SSP) to the target server (through the server-side SSP). With CredSSP enabled, the process that invokes a command remotely on Server1 passes the credential explicitly to Server2 during the first hop, and when Server2 needs to access Server3 for further activities during the same command execution, it uses the same credentials that was received from Server2 and so on.

Before enabling or activating CredSSP, it’s important that you understand the two type of roles involved in this process (Client and Server).

In CredSSP, the team Client is referred to the machines that starts the process of remote execution by passing the credentials. Servers are the machines that are accessed remotely.

In order to make a machine in your domain, allow incoming CredSSP connections, then you need to configure that machine with the role CredSSP server. 

The server role can be assigned by executing the command

Enable-WSManCredSSP -Role Server -Force.

To setup a machine to delegate credentials to the remote computer so every remote access from the remote machine will also work, you have to enable the Client role on that machine. The client role can be assigned by executing the command  

Enable-WSManCredSSP Client –DelegateComputer '*.mydomain.com' -Force

For e.g. if you have a build server in your domain that needs to execute a script block on an application server in your SharePoint farm, then you have to configure the Build server with the role client and the servers in the SharePoint farm with role both server and client (this is to make sure that these servers can pass and accept credentials during a second hop).

Under the hood, enabling WsManCredSSP will alter the WS-Management setting WSMAN:\localhost\Client\Auth\CredSSP to true on the client machine and WSMAN:\localhost\Service\Auth\CredSSP to true on the server machine. It will also take care of setting the local policy 'Allow delegating fresh Credentials' on the servers that are configured with Client role.