TL;DR: Unconstrained delegation lets a compromised server receive and reuse Kerberos ticket-granting tickets across the domain, creating a path to user impersonation and lateral movement, according to Semperis. The risk is not the setting alone but the way one exposed server can turn a single foothold into broad identity abuse.
At a glance
What this is: This is an analysis of unconstrained delegation in Active Directory and how it allows a server to capture Kerberos tickets and impersonate users across the domain.
Why it matters: It matters because Active Directory delegation settings can turn a single server compromise into domain-wide identity abuse, forcing IAM and PAM teams to treat delegation as a Tier 0 control issue.
Context
Unconstrained delegation is an Active Directory setting that allows a service or computer to receive a user's Kerberos ticket-granting ticket and act on that user's behalf across other network resources. The problem is not authentication itself, but the way ticket forwarding expands the trust boundary once a user connects to a delegated service.
For identity teams, this is a governance problem as much as a technical one. A server with unconstrained delegation becomes part of the privileged identity plane, because compromise of that host can expose tickets for users who never intended to trust it with domain-wide access.
The article sits squarely in NHI and human identity overlap: Kerberos tickets are human-authenticated credentials, but the abuse path depends on server-side delegation behaviour. That makes delegation settings, sensitive-account protections, and host tiering part of the same control discussion.
Key questions
Q: What happens when unconstrained delegation is enabled on a server that an attacker can control?
A: The server becomes a high value credential cache. An attacker can extract service tickets or a user’s TGT from memory, then impersonate that user to other systems in the domain. That turns one compromised host into a broader trust abuse path, which can expand access well beyond the original server and hide malicious activity behind a legitimate identity.
Q: Why does unconstrained delegation increase domain-wide abuse risk for privileged accounts?
A: Because the delegated server can replay a privileged user's ticket on the user's behalf, so the attacker inherits the victim's reach instead of needing a separate password or token. If the account is Tier 0 or domain-admin level, the blast radius extends to whatever that identity can access. The risk rises whenever privileged users can present tickets to a server that is not equally protected.
Q: What are the signs that unconstrained delegation has become a real exposure?
A: Look for servers with the setting enabled outside the small set of systems that truly need it, especially regular application servers that can receive privileged traffic. A dangerous pattern is when high-value accounts authenticate to those systems and delegation tickets appear in memory. That combination shows the setting is not just present, but operationally exploitable.
Q: What should teams do when a privileged account can be delegated to a non-tiered server?
A: They should treat that as an identity governance failure, not a host-hardening issue. The server is effectively inside the trust boundary of the privileged account, so the account and the host need to be separated immediately in policy. The right response is to block delegation for the privileged identity and reclassify the host according to the access it can receive.
Technical breakdown
How unconstrained delegation forwards Kerberos tickets
When a user authenticates to a service configured for unconstrained delegation, Kerberos can forward a ticket-granting ticket to that service and store it in memory. The service can then request or reuse credentials on the user's behalf when accessing other resources. That design is powerful because it removes the need for the service to hold the user's password, but it also means the host becomes a live repository of impersonation capability. If the host is compromised, the attacker does not need to crack the user's password. They can work with the delegated ticket material already present in memory.
Practical implication: Treat any server with unconstrained delegation as a high-value credential target and limit where that setting is allowed.
Why attacker discovery starts with directory enumeration
Attackers typically begin by querying Active Directory for systems with unconstrained delegation enabled. That discovery step matters because the setting is often spread across regular servers rather than just domain controllers, even though domain controllers already behave differently by default. Once a candidate host is identified, local administrative access on that host becomes the gateway to ticket capture. The attacker then monitors memory for incoming Kerberos tickets as users connect. This is why the exposure is not just about configuration drift. It is about the intersection of discoverable trust settings and the ability to turn host access into credential interception.
Practical implication: Continuously inventory delegation-enabled systems and review whether any non-essential server still needs the setting.
How captured tickets enable lateral movement and impersonation
Once an attacker captures a Kerberos ticket-granting ticket for a privileged user, they can impersonate that identity to reach other network resources as that user. In practical terms, the delegation setting converts one server compromise into a credential relay point for lateral movement. The article's example shows a Domain Admin ticket being captured after the account requested access to a CIFS service on a delegated server. That sequence is important because it shows the privilege does not have to originate on the compromised host. The host only needs to receive the ticket once, after which the attacker can reuse it for domain-wide abuse.
Practical implication: Classify delegated servers as Tier 0 assets and remove any path that lets high-privilege accounts present tickets to them.
Threat narrative
Attacker objective: The attacker wants to capture delegated Kerberos tickets, impersonate privileged users, and extend a single host compromise into domain-wide access.
- Entry begins with attacker discovery of servers configured for unconstrained delegation through Active Directory enumeration.
- Credential access follows when the attacker compromises a delegated server and waits for Kerberos ticket-granting tickets to be forwarded into memory.
- Escalation occurs when the attacker captures a privileged user's ticket and reuses it to impersonate that identity across the domain.
- Impact is domain-wide identity abuse and lateral movement through services the victim account could legitimately reach.
Breaches seen in the wild
- Cisco Active Directory credentials leak 2025: Kraken leaked Cisco Active Directory hashes, including service and krbtgt accounts; Cisco says they came from its 2022 breach, not a new one.
- Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Unconstrained delegation is an identity trust-extension problem, not just a legacy AD setting. The control effectively tells a server to hold and reuse user ticket material on behalf of that user. That means the server inherits part of the user's trust boundary, which is why the setting behaves like a hidden privilege amplifier rather than a simple compatibility feature. Practitioners should treat delegation scope as an access design decision, not a checkbox.
Ticket forwarding creates credential reuse debt inside the server memory model. Kerberos is designed to avoid password exposure, but unconstrained delegation moves the trusted material into a host that may not deserve that level of reach. Once the ticket is in memory, compromise of the machine becomes a credential access event. The implication is that host compromise and identity compromise are no longer separable for servers left in this state.
Domain-wide abuse emerges because the server becomes a proxy for user intent. The attacker does not need to forge identity from scratch if the server will accept and replay delegated tickets. This is why the control gap sits in authorization context, not authentication strength. The practical conclusion is that any delegated server handling privileged users must be governed as if it were already inside the privilege boundary.
Tiering is the only defensible way to contain delegated trust. If a server can receive tickets for high-value identities, it belongs in the same protection class as domain controllers and other Tier 0 assets. That is the governance lesson here: once delegation crosses into privileged identity paths, ordinary server hardening is no longer enough. Practitioners should align delegation policy with privileged access governance, not general server administration.
Active Directory delegation is now a security architecture issue across human and machine trust paths. The article shows how a human user's Kerberos session can be weaponised through a machine that was never meant to retain that trust. That bridge between human authentication and server-side replay is exactly where NHI-style governance thinking helps, because the host is acting as an identity-bearing intermediary. The field should recognise delegation settings as identity lifecycle and privilege containment problems, not just directory features.
What this signals
Delegation exposure is a privilege-boundary problem. Once a server can receive and replay user tickets, the boundary between authentication and authorisation collapses inside the host. That means teams should review delegation settings as part of privileged access governance, not as a standalone Active Directory hygiene task.
Server trust should be aligned to the identities it can impersonate. A regular application server that can impersonate a Domain Admin is already operating above its intended trust class. The practical signal for practitioners is to inventory every delegated host and decide whether its reach matches the identities that can touch it.
For practitioners
- Eliminate unconstrained delegation where possible Remove the setting from servers that do not have a strict business requirement for it, and prioritise any host that can receive privileged user tickets.
- Treat delegated servers as Tier 0 assets Place every server that must retain unconstrained delegation into the same protection and monitoring class as highly privileged identity infrastructure.
- Mark privileged accounts as non-delegable Use the Account is sensitive and cannot be delegated option for Tier 0 and other highly privileged identities so their tickets cannot be replayed through delegated hosts.
- Continuously inventory delegation exposure Use directory visibility tooling to identify user and computer accounts configured for unconstrained delegation and review them on a recurring basis.
Key takeaways
- Unconstrained delegation lets a delegated server receive Kerberos tickets and reuse them to impersonate users across the domain.
- The attack path matters because compromise of one delegated server can turn into credential access and lateral movement without cracking passwords.
- The control that changes the outcome is limiting delegation, classifying delegated hosts as Tier 0, and preventing privileged accounts from being delegated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Unconstrained delegation grants a server more identity reach than it should have. |
| NHI-10 — Human Use of NHI | Human logons create the ticket material that delegated servers can capture and replay. | |
| Recommendation — Remove delegation paths that let servers impersonate identities beyond their needed scope. Restrict privileged human accounts from authenticating to delegated hosts unless delegation is explicitly required. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article shows excessive trust exposure through delegated access in AD. |
| Recommendation — Apply least privilege to delegated servers and exempt high-value accounts from replayable trust paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Delegation settings are entitlements that expand who can act as whom. |
| Recommendation — Review and restrict delegation entitlements so access permissions match intended trust relationships. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's attack path centers on ticket capture and domain movement. |
| Recommendation — Map delegated-ticket abuse to credential access and lateral movement detections in your hunt process. | ||
Key terms
- Unconstrained Delegation: An Active Directory delegation mode that allows a service to reuse a user's Kerberos ticket after authentication. It is risky because the service can act on the user's behalf across the domain, so a compromise of that host can expose reusable identity authority.
- Kerberos Ticket-Granting Ticket: A Kerberos credential that proves the user has already authenticated and can request service tickets without re-entering credentials. In delegation scenarios, it becomes valuable because a service may store it in memory, making it a target for attackers who compromise the host.
- Delegated Trust Boundary: The line where an organisation relies on a third party or system to make decisions on its behalf. In agentic workflows, this boundary matters because a vendor-hosted agent may carry enough authority to expose data or trigger account actions without direct enterprise control.
- Tier 0 Asset: A system or identity with the highest privilege and trust in the environment, such as a domain controller or a privileged administrative account. These assets require the strictest segmentation, monitoring, and access controls because compromise can affect the entire directory.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org