PowerShell Remoting Double-Hop Authentication Failure

For the PowerShell remoting second-hop problem, the supported options in order of preference include CredSSP, resource-based Kerberos constrained delegation, and Kerberos constrained delegation. For WinRM/PowerShell remoting, legacy Kerberos constrained delegation does not support the second hop for WinRM, so if the scenario is specifically PowerShell remoting, use CredSSP or resource-based Kerberos constrained delegation instead.

CredSSP

Use CredSSP when a remote session on one server must access a second server, and explicit credentials are acceptable.

• CredSSP is disabled by default on both client and server.
• WinRM supports CredSSP only with explicit credentials.
• CredSSP works with Windows Server 2008 or later.
• Risk: CredSSP caches credentials on the remote server, which exposes them to credential theft if that server is compromised. Enable it only in highly trusted environments.
• Limitation: it does not work with the Protected Users group.

Kerberos constrained delegation

Legacy Kerberos constrained delegation can be configured with Use any authentication protocol to allow protocol transition, but:

• it doesn't support the second hop for WinRM,
• requires Domain Administrator access,
• must be configured on the Active Directory object of the intermediate server,
• is limited to one domain and cannot cross domains or forests,
• requires rights to update AD objects and SPNs.

Also, accounts marked Account is sensitive and can't be delegated cannot be delegated.

Resource-based Kerberos constrained delegation

For PowerShell remoting, this is the Kerberos-based approach documented for the second hop.

1. On the target server that hosts the resource, set PrincipalsAllowedToDelegateToAccount to the computer account of the intermediate server.
2. Example setup:

# Set up variables for reuse
$ServerA = $Env:COMPUTERNAME
$ServerB = Get-ADComputer -Identity ServerB
$ServerC = Get-ADComputer -Identity ServerC

3. Allow delegation from ServerB to ServerC:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

4. If ServerB is in another domain, specify the domain controller FQDN when retrieving ServerB:

# For ServerC in Contoso domain and ServerB in other domain
$ServerB = Get-ADComputer -Identity ServerB -Server dc1.alpineskihouse.com
$ServerC = Get-ADComputer -Identity ServerC
Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $ServerB

5. If access was previously denied, clear the Kerberos negative cache on the intermediate server before retesting. The KDC caches denied-access attempts for 15 minutes:

Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
    klist purge -li 0x3e7
}

Alternatively, restart the server or wait at least 15 minutes.

6. To remove the delegation setting later:

Set-ADComputer -Identity $ServerC -PrincipalsAllowedToDelegateToAccount $null

Important behavior for PowerShell remoting

WinRM runs as the computer account by default, so delegation for a remoting session must be granted to the computer object of the intermediate server.

Get-CimInstance Win32_Service -Filter 'Name="winrm"' | Select-Object StartName

Expected output:

StartName
---------
NT AUTHORITY\NetworkService

If no server-side delegation configuration is desired

A simpler alternative is to pass credentials inside a nested Invoke-Command script block:

$cred = Get-Credential Contoso\Administrator
Invoke-Command -ComputerName ServerB -Credential $cred -ScriptBlock {
    hostname
    Invoke-Command -ComputerName ServerC -Credential $Using:cred -ScriptBlock {hostname}
}

This avoids delegation setup, but requires supplying credentials in the script.

• Making the second hop in PowerShell Remoting
• Making the second hop in PowerShell Remoting
• Making the second hop in PowerShell Remoting
• Making the second hop in PowerShell Remoting
• Making the second hop in PowerShell Remoting
• Multi-Hop Support in WinRM