Diagnosing PowerShell Remoting Double-Hop Authentication Failures

Recognizable condition

You run a PowerShell remoting command that works on the first hop, but when the script inside that session tries to reach another computer (the second hop) you see errors such as:

• "Access is denied"
• "The WinRM client cannot process the request" with HTTP 401/500
• The command succeeds when you run it interactively on the first hop, but fails when invoked remotely.

This pattern indicates a double‑hop authentication problem: the delegated credentials from the original client are not being forwarded to the second hop.

Quick takeaway

Verify WinRM is healthy, test basic remoting, then decide whether to enable CredSSP (less secure) or configure Kerberos constrained delegation (preferred for production). Use the verification command at the end to confirm delegation succeeded.

Cause / diagnostic table

Symptom	Likely cause
"Access is denied" on second Invoke‑Command	No delegation configured (default Kerberos tickets are not forwardable)
"The WinRM client cannot process the request" with CredSSP error	CredSSP not enabled on client or server
Works interactively but fails in a scheduled task	Task runs without network credentials or under a account that cannot delegate

Ordered checks

1. Verify WinRM service on all machines

   Run on each hop (client, first‑hop, second‑hop):

   Get-Service winrm | Format-Table Name, Status, StartType

   Requires local administrator rights. Expect Status = Running.

2. Test basic remoting to the first hop

   From your management workstation:

   Enter-PSSession -ComputerName hop1 -Authentication Kerberos

   If this fails, the problem is before delegation; fix WinRM listeners or firewall (TCP 5985/5986).

3. Check the delegation method in use

   On the client:

   Get-Item WSMan:\localhost\Client\Auth\CredSSP

   Value true means CredSSP is enabled; false means Kerberos is being attempted.

   On the first‑hop computer, examine the AD computer object for constrained delegation:

   Get-ADComputer hop1 -Properties msDS-AllowedToDelegateTo | Select-Object -ExpandProperty msDS-AllowedToDelegateTo

   If the list is empty or missing the target SPN, Kerberos constrained delegation is not configured.

4. Validate SPNs for the target service

   On the second hop (or a domain controller):

   setspn -L hop2

   Look for entries like cifs/hop2.domain.com or HTTP/hop2.domain.com that match what the first hop will request.

   Duplicate SPNs cause authentication failures; note any conflicts for escalation.

5. Inspect WinRM and Security logs

   On the first hop, open Event Viewer → Applications and Services Logs → Microsoft → Windows → WinRM → Operational.

   Look for Event ID 91 (authentication success) vs 101 (failure) around the time of the test.

   Also check Security log for Event ID 4624 (logon type 3) to see if a network logon occurred.

Fixes tied to findings

When CredSSP is the chosen method

1. Enable CredSSP on the client (run as administrator):

   Enable-WSManCredSSP -Role Client -DelegateComputer *

   This allows the client to delegate credentials to any target; replace * with a specific hostname for tighter control.

2. Enable CredSSP on the server (first hop):

   Enable-WSManCredSSP -Role Server

3. Test:

   Invoke-Command -ComputerName hop1 -Authentication CredSSP -ScriptBlock { Invoke-Command -ComputerName hop2 -ScriptBlock { whoami } }

Limitation: CredSSP passes the user’s clear‑text credentials to the first hop, increasing credential‑theft risk. Use only in trusted environments and prefer Kerberos constrained delegation for production.

When Kerberos constrained delegation is preferred

1. Ensure the domain functional level is Windows Server 2012 or higher** (required for constrained delegation).
2. Configure the first hop to be trusted for delegation to the target service**

   On a domain controller (run as Domain Admin):

   Set-ADComputer hop1 -TrustedForDelegation $true -PrincipalsAllowedToDelegateToAccount (Get-ADUser hop2)

   Replace hop2 with the account that runs the service on the second hop (often a computer account).

3. Register the required SPN on the target service** (if missing):

   setspn -S cifs/hop2.domain.com hop2

4. Test** with Kerberos authentication:

   Invoke-Command -ComputerName hop1 -Authentication Kerberos -ScriptBlock { Invoke-Command -ComputerName hop2 -ScriptBlock { $env:USERNAME } }

Limitation: Requires domain admin rights to modify AD objects and may be blocked by Group Policy that overrides local CredSSP settings.

When the issue appears in scheduled tasks

1. Create or update the task to run with stored credentials and network availability**

   Register-ScheduledTask -TaskName "RemoteDoubleHop" -Action (New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-File C:\Scripts\DoubleHop.ps1') -Trigger (New-ScheduledTaskTrigger -AtLogOn) -User "DOMAIN\user" -Password (Read-Host -AsSecureString "Password") -RunOnlyIfNetworkAvailable:$true

2. Ensure the account has the "Log on as a batch job" right** on the first hop (via Local Security Policy).

Escalation criteria

Escalate to a domain administrator when:

• Duplicate SPNs are found (run setspn -X to list conflicts).
• Kerberos constrained delegation requires changes to msDS-AllowedToDelegateTo that you cannot perform due to lack of permissions.
• CredSSP deployment conflicts with organizational security policy (credential‑theft concerns).
• Firewall or network segmentation blocks TCP 5985/5986 between hops; verify with Test-NetConnection hop2 -Port 5985.

Verification command

After applying a fix, run this from your management workstation (replace hop1 and hop2 with your actual hostnames):

# Establish a session to the first hop
$s1 = New-PSSession -ComputerName hop1 -Authentication Kerberos
# Inside that session, reach the second hop
Invoke-Command -Session $s1 -ScriptBlock {
    Invoke-Command -ComputerName hop2 -ScriptBlock {
        whoami
        (Get-Item env:LOGONSERVER).Value
    }
}
# Clean up
Remove-PSSession $s1

If delegation succeeded, the output shows the username used on the second hop and the domain controller that authenticated it (e.g., DOMAIN\user and \\DC01). Any error indicates the delegation method is still misconfigured.
Practical way to check the result
Beyond the verification command, you can quickly confirm that a forwardable TGT exists on the first hop:

Enter an interactive session to the first hop:
Enter-PSSession hop1
Inside that session, list Kerberos tickets:
klist
Look for a ticket with the Forwardable flag set. If the flag is missing, Kerberos delegation is not working.

If you see the flag, the Kerberos path is correctly configured; if not, revisit the constrained delegation steps.

Note: PowerShell 7+ can bypass WinRM entirely by using SSH remoting (Enter-PSSession -HostName hop1). With SSH agent forwarding enabled (ForwardAgent yes in ~/.ssh/config) and key‑based authentication, double‑hop works without Kerberos or CredSSP. This is an alternative when Windows‑to‑Windows delegation is impractical.