Enable PowerShell Double-Hop Remoting

When working with PowerShell, there are cases when there is a need to remote into a computer with PowerShell session and perform tasks against another computer. These are some of the typical double hop scenario common in PowerShell.

To illustrate with a simple example, there is a user, testuser and his computer, client1 and there are two servers, server1 and server2. TestUser remotes to server1 using Enter-PSSession (first hop). Within that remote session, user executes WMI command to obtain the operating system version of server2 (second hop).

Note: TestUser could actually get the WMI information of server2 from client1, this is just a simple example.

When user remotes to the server1 from client1, how the user being authenticated and its credential passed to the server1 depending on the type of authentication. The first hop authentication usually is pretty straight forward and could be done using NTLM, Kerberos or other authentications. The tricky part is the authentication on the second hop. In order to allow user credential to be passed for second hop authentication, usually it uses kerberos authentication at both first and second hop. Keberos authentication requires all parties to be in the same active directory domain, SPN registration as well as user account enabled for delegation. However when kerberos delegation can not be used, PowerShell WinRM support Credential Security Service Provider (CredSSP) for authentication.

Here is the PowerShell commands for the above mentioned scenario without CredSSP,

PS C:\> $cred = Get-Credential
PS C:\> Enter-PSSession -ComputerName server1 -Credential $cred
[server1]: PS C:\Users\testuser\Documents> Get-WmiObject -Class Win32_OperatingSystem -ComputerName server2 | Select-Object -ExpandProperty caption

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

Checking the security log of server1, it uses kerberos authentication.

Since the account has not enabled for delegation on Active Directory, the Kerberos delegation can't be used for the second hop. The security log on server2 shows NT AUTHORITY\ANONYMOUS LOGON as the login credential, hence the access denied error.

To enable Credential Security Support Provider (CredSSP) authentication, run this command on client computer to enable client role and specify a computer to delegate the credential,

Enable-WSManCredSSP -Role Client -DelegateComputer server1.testdomain.com

If WinRM service is not running, you may receive this error.

Enable-WSManCredSSP : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150858770" Machine="client1.testdomain.com"><f:Message>The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig". </f:Message></f:WSManFault>

Run winrm quickconfig to verify if WinRM is setup correctly. Turn the WinRM service on when prompted (the service startup is also set to delayed auto start). Note, you don't need to allow remote access to the client machine if not required.

Now try to enable the CredSSP again.

On client computer,
Enable-WSManCredSSP -Role Client -DelegateComputer server1.testdomain.com

Note: you can use *.testdomain.com to allow all computers within the specified domain to be able to delegate the credential from this client.

To verify,
Get-WSManCredSSP

The machine is configured to allow delegating fresh credentials to the following target(s): wsm
an/server1.testdomain.com
This computer is not configured to receive credentials from a remote client computer.

Alternatively, you can verify through gpedit.msc.
Run gpedit.msc, expand Computer Configuration, expand Administrative Templates, expand System, select Delegation,

The 'Allow Delegating Fresh Credentials' should be enabled.

Double clicking the setting to view detail

Click the show button to see the list of servers that have been added to allow delegation.

On remote computer (e.g. server1 in this case)
Make sure that HTTP or HTTPS listener has been setup. Run winrm quickconfig to make sure it is properly setup.

Enable-WSManCredSSP -Role Server -Force

Notice that you can actually use PowerShell sessioon (pssession) to connect to the remote server and execute the command.

To verify,
Get-WSManCredSSP

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

Now, try again with our initial command. This time with the CredSSP authentication,

PS C:\> $cred = Get-Credential
PS C:\> Enter-PSSession -ComputerName server1-Credential $cred -Authentication Credssp

This error encountered,

Enter-PSSession : Connecting to remote server server1 failed with the following error message : The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials.  Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic.

The ComputerName specified has to match the DelegateComputer which is the FQDN (fully qualified domain name) specified earlier.

PS C:\> $cred = Get-Credential
PS C:\> Enter-PSSession -ComputerName server1.testdomain.com -Credential $cred -Authentication Credssp
[server1.testdomain.com]: PS C:\Users\testuser\Documents> Get-WmiObject -Class Win32_OperatingSystem -ComputerName server2 | Select-Object -ExpandProperty caption

Microsoft Windows Server 2008 R2 Standard

Here is the security log for server1. The first hop is using kerberos authentication. Subsequently, the WSMAN Negotiate authentication for the CredSSP.

Since the client1 has been setup to allow server1 to delegate its user credential (TestUser) through CredSSP, the second hop authentication uses kerberos authentication with TestUser credential.