The Kerberos Double Hop Problem happens when a service receives a user’s Kerberos credentials but cannot forward them to a second service on the user’s behalf. The result is failed access to downstream resources even though the first hop succeeded. Administrators usually address it by reviewing delegation design and service authentication flow, not by weakening Kerberos controls.
Why the Double Hop Breaks Kerberos Flow
The double hop is not a failure of Kerberos itself so much as a boundary in how delegated access is allowed to move. The first service can accept the user’s ticket, but unless the service is configured to delegate on behalf of that user, it cannot present usable credentials to a second service. That is why the first request succeeds while the downstream call fails.
In practice, the problem shows up most often in multi-tier Windows environments where one service must query another service, file share, database, or back-end API using the original user context. The service can authenticate the user, but the user’s Kerberos proof is not automatically transferable across the next hop.
What makes the issue confusing is that it often looks like an authorization failure at the second system. The real issue is usually earlier in the chain: the service account, SPN setup, or delegation model does not support the forwarding pattern the application expects.
How Delegation and Service Context Drive the Outcome
The practical distinction is between authenticating a user and being trusted to act for that user elsewhere. If delegation is absent or incorrectly scoped, the middle-tier service becomes a dead end for the user’s Kerberos context. That is why solutions typically involve constrained delegation, protocol transition design, or redesigning the service flow rather than weakening Kerberos protections.
Where teams need a deeper delegation reference, the Kerberos Delegation Security Guide covers the common delegation modes, including constrained delegation, protocol transition, and resource-based constrained delegation abuse patterns. For the broader authentication and ticketing model behind the behavior, the Kerberos Security Guide is the better starting point.
One important nuance is that the service’s own identity matters. If the back-end call is made with a different service account, or if the application hides the original user context behind a separate technical credential, the second system will not see the same identity relationship the application owner assumed. That mismatch is often the real reason the hop fails.
What Practitioners Should Check First
Start by tracing the exact authentication path: which account authenticates the user, which account calls the downstream service, and whether the application is supposed to use delegation at all. That simple mapping usually reveals whether the failure is caused by missing delegation trust, an SPN issue, or a design that should not rely on forwarded user context.
For teams dealing with constrained or risky delegation patterns, the Kerberos Delegation Security Guide also helps separate legitimate delegation from abuse-prone configurations such as unconstrained delegation and RBCD misuse. That matters because fixing the double hop should not create a broader trust expansion than the application actually needs.
When the application truly needs downstream access on behalf of the user, validate that the design uses the smallest delegation scope that still works. When it does not, prefer an application pattern that passes an application token, uses a back-end service identity, or shifts the downstream access decision to a component that is meant to own it.
Risk and Threat Considerations
The security risk is usually not the failed second hop itself, but the temptation to solve it by broadening trust. Overly permissive delegation can turn a narrow application need into a path that exposes back-end services to impersonation or credential misuse.
Failure mechanism: A service is allowed to receive a user’s Kerberos ticket but lacks the delegation trust or authentication flow needed to obtain usable downstream credentials, so the user context dies at the intermediate tier.
Impact: Legitimate workflows fail, and rushed workarounds can expand delegation scope, increase lateral movement potential, or expose sensitive downstream resources to impersonation risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The issue centers on service-to-service authentication and delegated access. |
| AC-6 — Least Privilege | Delegation scope must stay minimal to avoid overbroad downstream authority. | |
| IA-5 — Authenticator Management | Kerberos tickets and related credentials must be managed carefully across hops. | |
| Recommendation — Enforce service authentication boundaries before allowing downstream access on behalf of a user. Restrict delegated rights to the smallest set needed for the back-end request. Control credential lifecycle and renewal rules for any authentication material used in delegation. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The problem reflects trust boundaries and explicit authorization between tiers. |
| Recommendation — Design each tier to verify access explicitly instead of assuming user context can pass unchanged. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Delegated access paths and service permissions must be inventoried and limited. |
| Recommendation — Inventory and constrain service permissions that enable cross-tier access. | ||
Practitioner Guidance
What to verify: Confirm whether the application is supposed to forward user context or whether it should use a separate service identity for the back-end call. That decision determines whether delegation is a requirement or a design smell.
Decision rule: If the user identity must flow to the second service, treat delegation design as the control point. If it does not need to flow, redesign the application so the second hop is made with an explicit service-to-service trust relationship instead of ad hoc forwarding.
Common mistake: Teams often try to “fix” the double hop by loosening Kerberos settings broadly, when the safer answer is usually to correct the service authentication flow or scope delegation narrowly.
Practitioner takeaway: The double hop problem is best treated as an architecture and trust-design issue, not a Kerberos defect, and the safest fix is the one that preserves least privilege while making the downstream access path explicit.