Skip to main content
The Kerberos double hop problem shows up when connecting to a remote server via PowerShell Remoting/WinRM (hop 1) and then trying to use that session to reach a third server (hop 2). By default, Windows won’t forward the credentials used for hop 1 onward to hop 2, so whatever runs on the third server fails to authenticate, even though the identity looks right.
This bites Pass-the-Ticket workflows specifically: a TGT that authenticates fine to the first host doesn’t automatically authenticates to the second host.

​
Workaround #1: PSCredential Object

Explicitly creates a credential object inside the session and passes it directly to the next command, giving that command the exact identity it needs for the second hop without relying on delegation at all.

​
Workaround #2: Register PSSession Configuration

Registers a persistent, custom endpoint on the remote server that always executes commands under a specific RunAs security context, so the double-hop never needs to happen in the first place.

​
Quick Reference Tools

Pass-the-Ticket

The ticket-reuse workflow that most often runs into this problem.

Remote Access & Execution

The Enter-PSSession baseline this problem builds on.

slayerlabs: Double Hop

Deeper write-up covering further solutions (CredSSP, Kerberos unconstrained/constrained delegation).