PowerShell Remoting Double-Hop Authentication Failure

Question

Executing a remote PowerShell script on Server A that attempts to access a file share on Server B fails with Access Denied.

How do we configure Credential Security Support Provider (CredSSP) or Kerberos Constrained Delegation to enable multi-hop authentication?

Answer 1

Hello,

The “Access Denied” you’re hitting is a classic double-hop authentication problem. When you run a remote PowerShell session from Server A, the credentials are valid only for that first hop. By default, they cannot be reused to access Server B’s file share. To solve this, you either enable CredSSP for delegation or configure Kerberos Constrained Delegation (KCD), depending on your security requirements.

CredSSP is the simpler option but less secure. You enable it on both the client and the target by running Enable-WSManCredSSP -Role Client -DelegateComputer ServerA on the initiating machine, and Enable-WSManCredSSP -Role Server on the remote host. Then you invoke your session with Enter-PSSession -ComputerName ServerA -Authentication CredSSP -Credential <domain\user>. This allows the credentials to be delegated to Server B. The downside is that CredSSP passes credentials in a way that increases exposure risk, so it should only be used in tightly controlled environments.

Kerberos Constrained Delegation is the recommended enterprise-grade solution. You configure this in Active Directory by editing the properties of the Server A computer account. In the Delegation tab, select “Trust this computer for delegation to specified services only” and choose “Use Kerberos only.” Then add the CIFS service for Server B (e.g., cifs/ServerB.domain.local). This allows Server A to delegate Kerberos tickets specifically for accessing Server B’s file shares. Once configured, remote PowerShell sessions from Server A can access Server B without failing on the second hop, and you avoid the security risks of CredSSP.

If you are running Windows Server 2016 or later, Microsoft explicitly recommends KCD over CredSSP for multi-hop scenarios, especially in production terminal server or RDS environments. CredSSP should be reserved for testing or isolated systems.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Answer 2

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