Ticket-Granting Ticket Delegation

How Ticket-Granting Ticket Delegation Works

Ticket-Granting Ticket Delegation is a Kerberos flow that lets one service act on a user's behalf to obtain more tickets for downstream services. The practical effect is a delegated security context, which is what makes multi-tier application designs workable, but also what makes the mechanism sensitive to scope, trust, and ticket handling.

In Kerberos, the delegated ticket is not just a convenience token. It can carry forward the user's authority into later service calls, so the security boundary is no longer limited to the first hop. That is why delegation design has to be treated as part of authorization architecture, not just as an authentication feature.

Kerberos Security Guide covers the wider Kerberos mechanisms that underpin delegation, including ticket handling, trust paths, and common abuse patterns.

Why Delegation Exists in Multi-Tier Systems

Delegation is used when a front-end service must call another back-end service while preserving the user's identity or authorization context. That enables end-to-end business logic such as application servers reaching databases, file services, or internal APIs without forcing every component to reauthenticate the user separately.

This pattern is valuable because it avoids flattening access into a single shared technical account. It also preserves accountability, since downstream actions can still be tied back to the original user rather than to a generic service identity.

RFC 8693: OAuth 2.0 Token Exchange is a useful analogue for understanding on-behalf-of access, even though Kerberos delegation and OAuth token exchange are different mechanisms.

Why Delegation Is Security-Sensitive

Delegation expands the reach of a user session, so any weakness in service trust, delegation scope, or ticket protection can widen access well beyond the original hop. If the delegated ticket is replayed, abused, or handed to an unintended service, an attacker may inherit a user's access path into additional systems.

That is why constrained delegation exists. The goal is to limit which services can receive delegated credentials and to reduce the blast radius if one service is compromised or misconfigured.

Delegation also creates a monitoring challenge. The activity often looks like normal service-to-service traffic, so defenders need to understand which services are allowed to obtain tickets on behalf of users and whether those paths match the intended application design.

Failure mechanism: A service with excessive or poorly scoped delegation can obtain tickets for more services than it should, turning a single compromised application into a broad trust bridge across the environment.

Impact: Attackers can move laterally through trusted application tiers, access downstream resources as the user, and abuse the delegated context to reach data or systems that were never meant to be directly exposed.

How to Govern and Validate Delegation

Practitioners should treat delegation as a trust-control decision, not a default application setting. The core question is which services genuinely need to act on behalf of users and which should use separate service credentials, explicit authorization, or a different architectural pattern instead.

Review the service inventory, the delegation configuration, and the actual request paths together. If a service can obtain additional tickets but does not need that capability for its business function, the configuration is stronger than the requirement and should be narrowed.

NIST AI Risk Management Framework is not specific to Kerberos, but its emphasis on governance and controlled use of delegated capability maps well to the trust decisions that delegation demands.

NIST SP 800-207 Zero Trust Architecture reinforces the design principle behind constrained delegation: do not assume a service should inherit broad trust just because it is inside the same system boundary.

Detection and Post-Compromise Review

After a suspected compromise, delegation paths should be reviewed alongside normal Kerberos activity because an attacker may use the mechanism to extend access without creating obvious authentication failures. Unusual ticket acquisition patterns, unexpected downstream service access, or service accounts reaching new resources can all indicate abuse of delegated authority.

The investigation should answer two questions: which service was allowed to delegate, and which downstream services were actually reached with that delegated context. That distinction matters because compromise may occur in the first service while the real business impact appears several hops later.

MITRE ATT&CK Enterprise Matrix is helpful for mapping delegated-ticket abuse to credential access, lateral movement, and privilege escalation behavior during detection and response.

NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control lens for access enforcement, auditability, and account lifecycle review when delegated access needs to be validated after an incident.

Risk and Threat Considerations

Ticket-Granting Ticket Delegation is dangerous when trust is broader than the business requirement. The risk is not the existence of delegation itself, but the combination of delegated authority, downstream reach, and weak scoping or monitoring.

Failure mechanism: A compromised or over-trusted service can reuse delegated tickets to request additional access, letting an attacker extend a foothold across application tiers while appearing to operate through legitimate service paths.

Impact: The result can be lateral movement, unintended data access, and a larger blast radius than the first compromised service would otherwise allow.

Practitioner Guidance

Why practitioners should care: Delegation should be granted only where the application design truly depends on it. The safest posture is to limit the number of services that can carry user context onward and to keep the trust relationship as narrow as the workflow permits.

What to watch for: Look for services that obtain tickets on behalf of users without a clear downstream business need, especially where the same path could expose sensitive internal services or administrative functions.

Practitioner takeaway: If a service can delegate, assume it can also amplify compromise unless you have explicitly bounded what it may request and where that delegated context may go.

Related resources from NHI Mgmt Group

• Kerberos Ticket-Granting Ticket
• Kerberos Ticket Granting Service (TGS)
• How can organizations effectively manage access delegation for AI agents?
• How should teams respond when a secret is found in a support ticket?