Kerberos Delegation

Expanded Definition

Kerberos delegation is the mechanism that lets a service use a client’s Kerberos identity to request access from another tier, rather than falling back to the service account’s own privileges. In NHI environments, this matters because the delegated identity can carry broader reach than the front-end service was originally meant to hold.

Definitions vary across vendors and implementation guides, especially around constrained delegation, protocol transition, and whether a service is acting as a true intermediary or as an identity broker. The operational concern is the same: delegation extends the trust boundary and can silently convert a routine tier-to-tier call into a privilege-bearing action. That is why it should be evaluated alongside NIST Cybersecurity Framework 2.0 access governance expectations and the broader NHI controls discussed in Ultimate Guide to NHIs.

The most common misapplication is enabling delegation to a downstream system simply because the application team needs end-to-end user context, which occurs when administrators treat convenience as a substitute for trust scoping.

Examples and Use Cases

Implementing Kerberos delegation rigorously often introduces tighter trust boundaries and more complex troubleshooting, requiring organisations to weigh user-context fidelity against attack surface expansion.

• A web front end forwards a user’s Kerberos identity to an application server so the application can query a database as that user, preserving audit context but widening the path of trust.
• An internal portal uses constrained delegation to call a reporting service, limiting which downstream services may be reached and reducing the blast radius if the portal is compromised.
• A legacy line-of-business system relies on protocol transition so a non-Kerberos entry point can still obtain a delegated ticket, which increases administrative risk if the transition path is over-permissive.
• Security teams review delegation settings after mapping service accounts and SPNs, using the visibility guidance in Ultimate Guide to NHIs to confirm that only intended service paths can impersonate users.
• Identity architects align tiered application patterns with Kerberos guidance from NIST Cybersecurity Framework 2.0, then verify that the delegated hop is restricted to the minimum required target.

Why It Matters in NHI Security

Kerberos delegation becomes a high-value control point because it often sits at the intersection of service accounts, API-like backend calls, and inherited user authority. When delegation is too broad, a compromise in one tier can be used to move laterally into sensitive systems, even when the original application appears low risk. That is especially dangerous in environments where service accounts already have excessive privileges.

NHI Mgmt Group research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which makes any delegation path worth scrutinising as a potential escalation channel. Delegation should therefore be governed with the same discipline applied to secrets, service account lifecycle, and Zero Trust access decisions. The most effective way to think about it is as a privilege amplifier that must be explicitly bounded, logged, and periodically reviewed rather than assumed safe because it is part of a normal application flow.

Organisations typically encounter the consequences only after a service account compromise or a suspicious downstream access event, at which point Kerberos delegation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How can organizations effectively manage access delegation for AI agents?
• How should security teams handle unconstrained delegation in Active Directory?
• Why does unconstrained delegation increase the risk of lateral movement?
• What is the difference between unconstrained and constrained delegation?