The Kerberos Double Hop Problem is the inability of a service to reuse a user’s Kerberos credentials when that service must access another network resource on the user’s behalf. It breaks delegated access in multi-tier applications unless delegation is configured correctly. Defenders should design for explicit delegation controls and avoid workarounds that weaken authentication.
How the Kerberos Double Hop Problem Works
The double hop problem appears when a service receives a Kerberos-authenticated request and then needs to access a second system on the caller’s behalf. Kerberos protects the first hop well, but the second hop fails unless delegation is explicitly designed into the flow.
This makes the issue less about “Kerberos not working” and more about how delegation is preserved across tiers. In practice, the service has to present a delegated identity or ticket that the downstream system will accept, otherwise the request stops at the boundary between the middle tier and the backend resource.
Why Multi-Tier Applications Run Into It
The problem shows up most often in applications with a front end, an application tier, and a data or file tier. The user authenticates to the first service, but that service cannot automatically re-use the user’s credentials for backend access because Kerberos is intentionally restrictive about credential forwarding.
That restriction is a security feature, not a defect. It prevents a service from silently becoming a generic proxy for a user unless the environment explicitly authorises delegation. Microsoft environments often surface this in web apps, reporting tools, and administrative workflows that need to query another server after the initial sign-in.
Kerberos Delegation Security Guide is the best companion resource when you need the broader delegation model, including constrained delegation, protocol transition, and RBCD.
Security Implications and Design Trade-offs
The core security trade-off is between usability and delegated authority. If teams solve the double hop by relaxing authentication controls or by using over-broad delegation, they can accidentally expand the blast radius of a compromised middle tier.
Because the middle service may gain the ability to act for a user against downstream systems, delegation settings become a privilege boundary. That means the design should preserve least privilege and make the trust path explicit, rather than treating “make it work” as the only requirement.
Kerberos Security Guide helps place the double hop issue in the wider Kerberos threat landscape, including ticket abuse and detection concerns that often sit next to delegation failures.
Where to Check and Fix the Problem
When a double hop issue appears, the first checks are usually architectural: identify which service is making the downstream call, what account it runs under, and whether the backend resource expects delegated user context or service-to-service access. The right fix depends on the trust relationship, not just the error message.
Teams should validate whether delegation is actually required, whether the downstream system can accept application credentials instead, and whether the current design leaks into unsafe workarounds such as embedding reusable credentials in scripts or application config. For authoritative platform-specific guidance, use the vendor’s Kerberos documentation and configuration guidance rather than inferring the correct delegation pattern from symptoms alone.
NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control backdrop for access control, identification and authentication, and credential management decisions around delegated access.
Risk and Threat Considerations
The danger is not the hop failure itself, but the ways people sometimes bypass it. Workarounds that weaken authentication or broaden delegation can turn a routing problem into an authorization problem, especially if the middle tier is exposed or lightly monitored.
Failure mechanism: A service that cannot legitimately delegate a user’s Kerberos context may be tempted to use shared service credentials, unconstrained delegation, or stored secrets to reach the backend, which expands trust and creates a reuse path for attackers.
Impact: If the middle tier is compromised, an attacker may be able to reach downstream resources as the service or even as the user, increasing the chance of lateral movement, data access, and privilege abuse.
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, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Double hop fixes often hinge on credential handling and delegated access paths. |
| AC-6 — Least Privilege | Delegation should grant only the access needed for the downstream call. | |
| IA-9 — Service Identification and Authentication | The middle tier and downstream resource rely on service-to-service trust during delegated access. | |
| Recommendation — Manage delegated credentials carefully and avoid storing reusable secrets to bypass Kerberos delegation. Limit delegated backend access to the minimum permissions required by the application. Authenticate services explicitly when they act on behalf of users across tiers. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Kerberos delegation is an access-control design choice that must be governed. |
| Recommendation — Define and review delegated access paths so services do not gain broad implicit trust. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The problem is fundamentally about preserving trust boundaries across tiers and services. |
| Recommendation — Verify each tier independently instead of assuming user authentication automatically extends downstream. | ||
Practitioner Guidance
Governance implication: Treat delegated access as an explicit design decision, not a troubleshooting convenience. The question to answer is not “how do we bypass the double hop?” but “what is the minimum trusted delegation path that preserves the required user experience?”
Practitioner note: The safest patterns are the ones that make the identity boundary visible. If a workflow needs downstream access on a user’s behalf, document the delegation model, confirm the backend trust expectation, and avoid introducing reusable credentials just to eliminate an error.