Why does unconstrained delegation create such a high impersonation and lateral movement risk in Active Directory?

Why Unconstrained Delegation Becomes an Impersonation Problem

Unconstrained delegation is dangerous because it turns a server into a reusable trust boundary for other users’ Kerberos access. When that server is allowed to cache incoming tickets, compromise of the host is no longer a simple machine compromise; it becomes a way to recover credentials that can speak as a user across the domain. The risk is not only theft of access, but theft of delegated trust that can be replayed into other services.

That matters most when the server accepts connections from privileged accounts, administrators, or accounts with broad application reach. In those cases, an attacker does not need to break the authentication system itself. They only need one delegated host, one memory harvest opportunity, and one valid ticket stream to move from local foothold to domain-wide impersonation potential. The control is therefore risky by design because it concentrates identity power in a place that is usually harder to harden than a directory policy.

In practice, many security teams discover the exposure only after a delegated server has already been used as the bridge into higher-value accounts.

How It Works in Practice

In Kerberos, unconstrained delegation lets a service receive and reuse a user’s delegated credentials when the user authenticates to that service. The technical problem is that the server is trusted to hold those tickets, so compromise of the host can reveal session material from memory. Once an attacker has that material, they can impersonate the user to other services that accept Kerberos, including services the user would normally access only under narrow conditions.

The lateral movement risk grows because the attack path is built on legitimate trust relationships rather than obvious privilege escalation tooling. An attacker with control of a delegated host can often target:

• administrative users who connect for management or support
• service accounts that reach multiple internal systems
• applications that inherit broad directory trust
• any service where the stolen ticket is still accepted before expiration

That is why the issue is more than “credential theft.” The host effectively becomes a collection point for reusable identity artifacts, and those artifacts may unlock more than one downstream system. Good Kerberos hygiene, constrained delegation, and minimised server trust are central here, because the attack succeeds by abusing normal authentication semantics, not by breaking encryption. Guidance from the MITRE ATT&CK Enterprise Matrix helps teams map this behaviour to credential access and lateral movement patterns, while NHI-focused analysis such as Top 10 NHI Issues is useful for understanding how delegated trust can expand blast radius across machine and service identities. These controls tend to break down when legacy application servers still require broad delegation because the trust exception becomes more valuable than the security boundary.

Common Variations and Edge Cases

Tighter delegation controls often increase application friction, so organisations have to balance compatibility against impersonation risk. That tradeoff is especially sharp in older environments where applications were built assuming broad Kerberos delegation would “just work.”

Not every delegated host is equally dangerous. Risk rises sharply when the server is internet-facing, reachable by privileged users, or shared across many workloads. It is also worse when service accounts are reused, when administrators log on interactively to application servers, or when the same host supports both user traffic and back-end service calls. In those environments, one compromise can bridge multiple trust tiers.

Current guidance suggests treating unconstrained delegation as an exception state rather than a normal design choice. Organisations that still need delegated authentication should limit where it exists, separate privileged administration paths from application tiers, and verify that the delegated surface cannot cache credentials from accounts whose compromise would change the domain risk profile. A useful reference point is the MITRE ATT&CK Enterprise Matrix, which shows how credential access and lateral movement chain together once trust is abused. The pattern is most fragile in environments with shared admin access and long-lived service relationships, because those conditions turn a single delegated host into a high-value impersonation node.

Risk and Threat Considerations

Unconstrained delegation creates a concentrated trust exposure: compromise of one server can expose reusable Kerberos material for users who authenticated to it. That makes the control attractive to attackers seeking privilege amplification, not just endpoint control.

Failure mechanism: The attacker compromises the delegated host, extracts cached tickets from memory, and reuses them to authenticate as the victim to other services before ticket expiry. The attack works because the host is allowed to hold delegated credentials, so the trust boundary is already weakened by design.

Impact: The result can be impersonation of privileged users, access to adjacent systems, lateral movement across the domain, and in severe cases access paths that support broader domain compromise.

Practitioner Guidance

What to prioritise: Inventory every unconstrained delegation setting first, then rank hosts by whether they ever receive privileged user sessions. A delegated application server that never sees admin traffic is still risky; one that does should be treated as an urgent containment candidate.

What to verify: Confirm whether the service truly requires unconstrained delegation or whether constrained delegation or a different authentication design will satisfy the business case. Also verify where privileged users log on, because the security impact is driven as much by who authenticates as by which host is trusted.

Common mistake: Treating delegation as an application convenience instead of a domain trust decision. Once that distinction is missed, teams tend to harden the server but leave the identity exposure intact.

Practitioner takeaway: The real issue is not that a server can authenticate on behalf of someone else; it is that compromise of that server can turn ordinary user trust into a reusable path for impersonation and lateral movement.

Related resources from NHI Mgmt Group

• Why does Active Directory compromise create such broad risk across enterprise systems?
• Why do AI ETL libraries create such high lateral movement risk?
• Why does Kerberos delegation create such a large risk in Active Directory?
• Why do dMSAs and gMSAs still create lateral movement risk in Active Directory?