Kerberos Delegation

How Kerberos Delegation Works

Kerberos delegation lets a service present a caller’s identity to another service, so the downstream system can make an access decision as if the original user initiated the request. That makes it useful for multi-tier applications, but it also widens trust beyond the first hop and means the delegated service is effectively acting with borrowed authority.

Because the downstream resource sees the caller’s context, delegation is not just a transport detail. It becomes part of the authorisation model for the whole application path, and the security question shifts from “can this service authenticate?” to “should this service ever be allowed to speak for someone else?”

Common Delegation Models and Trust Boundaries

Kerberos environments typically distinguish between unconstrained delegation, constrained delegation, and resource-based constrained delegation. The practical difference is how narrowly the trust is scoped, which services can receive delegated tickets, and whether the target resource or the source service defines that trust relationship.

In security terms, the key issue is delegation scope. Broader delegation means a compromise of one trusted service can expose a much wider set of downstream resources. Narrower delegation reduces blast radius, but it still requires careful review because any service that can obtain forwarded access is operating inside a sensitive trust boundary. The Kerberos Delegation Security Guide is useful for understanding the difference between unconstrained delegation, constrained delegation, and resource-based constrained delegation in operational terms.

Why Delegation Creates Security Risk

Delegation is dangerous when the delegated service is high value, widely reachable, or able to reach sensitive back ends. If an attacker compromises that service, they may be able to reuse delegated authority to move laterally, impersonate users to other systems, or access resources that were never directly exposed to the attacker.

This is why sensitive accounts and highly privileged targets should be excluded from delegation wherever possible. Kerberos delegation can also become an escalation path when protocol transition, service ticket handling, or overly broad trust relationships allow a service to act beyond the minimum needed for its job. The Kerberos Security Guide is a useful companion reference for related ticketing, pre-authentication, and delegation abuse patterns.

How Organisations Assess Exposure and Reduce Blast Radius

Exposure review starts with inventory: which services are trusted for delegation, which accounts they can impersonate, and which back-end systems accept the forwarded context. Teams should also check whether any internet-facing or broadly reachable service has delegation enabled, because that combination greatly increases the chance that a single compromise can be turned into a larger trust breach.

Reduction of blast radius usually means tightening trust relationships, protecting sensitive accounts from delegation, and reviewing whether a business process really needs delegated identity at all. In some architectures, the safer answer is to redesign the call path so the downstream service authorises the action without inheriting the original caller’s full context. Where an access model depends on forwarded credentials or token exchange, RFC 8693: OAuth 2.0 Token Exchange provides a useful delegation analogue for understanding controlled on-behalf-of flows.

Risk and Threat Considerations

Kerberos delegation is risky because it turns a service compromise into a potential impersonation path. If an attacker gains execution on a delegating service, they may abuse the trusted relationship to reach systems that would otherwise reject their direct access.

Failure mechanism: Overbroad delegation trust, especially to sensitive targets, lets a compromised service request or reuse downstream access in the caller’s context, enabling lateral movement or privilege escalation.

Impact: Attackers can access protected resources, impersonate users to back-end systems, and expand a single service compromise into domain-wide exposure.

Practitioner Guidance

Governance implication: Treat delegation as an explicit trust decision, not a default feature of service integration. Each delegated relationship should have a named owner, a business justification, and a clear sensitivity review for the target resources it can reach.

What to watch for: Repeated use of delegation to reach privileged systems, delegation enabled on services that do not clearly need it, and any account or resource marked sensitive enough that delegated use should be blocked. Delegation paths should be reviewed alongside service hardening and access reviews, not after an incident.

Related resources from NHI Mgmt Group

• How should security teams govern Kerberos delegation for machine accounts?
• What breaks when Kerberos delegation validation is weakened?
• Why does Kerberos delegation create such a large risk in Active Directory?
• Who is accountable when a Kerberos delegation flaw leads to domain compromise?