By NHI Mgmt Group Editorial TeamPublished 2026-02-02Domain: Workload IdentitySource: Semperis

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 impersonate users after authentication.

Why it matters: It matters because unconstrained delegation turns one compromised host into a domain-wide identity risk, which is exactly the kind of trust assumption IAM and NHI teams need to constrain.

👉 Read Semperis's analysis of unconstrained delegation in Active Directory


Context

Unconstrained delegation is an Active Directory trust pattern that lets a service reuse a user's Kerberos ticket after the user authenticates. In NHI governance terms, it creates a non-human identity risk because a server can act with borrowed user authority well beyond the original access request. That is a classic identity blast-radius problem, not just an AD configuration issue.

The security concern is simple: if an attacker compromises a server with unconstrained delegation, they may capture ticketing material in memory and use it to move across the domain. For IAM and NHI practitioners, the core question is not whether delegation is convenient, but whether the trust boundary is narrow enough for Tier 0 and other privileged systems. The starting position described in the source is common enough to warrant defensive redesign, not exception handling.


Key questions

Q: How should security teams handle unconstrained delegation in Active Directory?

A: Security teams should remove unconstrained delegation wherever possible and treat any remaining hosts as high-risk identity assets. If a service must keep delegation, place it under Tier 0 controls, restrict administrative access, and monitor for ticket exposure in memory. The goal is to shrink the number of places where reusable Kerberos authority can be observed or abused.

Q: Why does unconstrained delegation increase the risk of lateral movement?

A: Unconstrained delegation increases lateral movement risk because a compromised server can reuse Kerberos ticketing material to impersonate users who authenticate to it. An attacker does not need to steal passwords from scratch if they can capture a ticket already trusted by the domain. That turns one host compromise into a broader identity abuse path.

Q: What is the difference between unconstrained and constrained delegation?

A: Unconstrained delegation lets a service reuse user tickets across the domain, while constrained delegation limits the service to specific downstream services and access paths. The first creates a much larger blast radius if the host is compromised. The second narrows trust and is better aligned with least privilege.

Q: When should a privileged account be marked as sensitive and cannot be delegated?

A: Privileged accounts should be marked as sensitive and cannot be delegated whenever their tickets must not be forwarded through less trusted systems. That is especially important for Tier 0 identities, domain admins, and other accounts that should never appear in delegation workflows. The flag is a containment control, not a complete delegation strategy.


Technical breakdown

How unconstrained delegation turns Kerberos tickets into reusable authority

With unconstrained delegation, a service receives a forwardable Kerberos ticket-granting ticket after a user authenticates. The ticket is stored in memory so the service can request additional service tickets on the user's behalf. That makes the service a delegated identity container, not just an application host. If the host is compromised, the attacker inherits that reusable authority and can impersonate users as they access other resources. This is why delegation settings are identity controls, not merely application settings.

Practical implication: Treat every unconstrained delegation host as a high-value identity asset and remove the setting wherever possible.

Why server compromise becomes domain impersonation

The attacker workflow is straightforward. First, they identify computers with unconstrained delegation enabled. Next, they gain local administrative access and watch memory for incoming Kerberos tickets when users request services. Because the ticket is already trusted by the domain, the attacker does not need to forge authentication from scratch. They can wait for a privileged user, capture the ticket, and reuse it for access to other network resources. This is a trust amplification problem: one server becomes a bridge into broader domain authority.

Practical implication: Prioritise detection and containment on any host that can observe privileged ticket traffic.

Why tiering and sensitivity flags matter for delegated identities

The source recommends treating unconstrained delegation hosts as Tier 0 if the setting cannot be removed. That maps to a simple control principle: if a host can observe or reuse privileged identity material, it belongs in the same protection class as the identities it can affect. Marking Tier 0 accounts as sensitive and cannot be delegated reduces abuse potential, because those accounts should not be forwarded into risky trust paths. The control is defensive, but the structural fix is to stop relying on unconstrained delegation as a design pattern.

Practical implication: Protect privileged accounts from delegation paths and move to constrained or non-delegated designs.


Threat narrative

Attacker objective: The attacker aims to capture reusable Kerberos authority and turn one compromised server into domain-wide impersonation capability.

  1. Entry begins when the attacker identifies servers with unconstrained delegation enabled and later compromises one of those hosts.
  2. Escalation occurs when the attacker gains local admin access and monitors memory for Kerberos ticket-granting tickets issued to other users.
  3. Impact follows when the attacker reuses a captured privileged ticket to impersonate a domain user and access additional network resources.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Unconstrained delegation is an identity blast-radius problem, not a legacy AD curiosity. Once a service can receive and reuse Kerberos ticketing material, it becomes a high-trust identity node with consequences far beyond its workload. That shifts the issue from administration convenience to governance risk. Practitioners should classify delegation paths as part of the privileged access model, not as a passive directory feature.

Tiering only works when identity forwarding is treated as a high-risk control surface. The source correctly frames Tier 0 accounts as sensitive, but the same logic must extend to any host that can observe or reuse privileged tickets. If a server can become a credential collection point, it deserves elevated monitoring and restrictive placement. Security teams should align delegation exposure with PAM and ZTA thinking, not leave it buried in AD exceptions.

Constrained alternatives are not optional once attackers target memory-resident tickets. The operational lesson is that attack paths exploit trust already granted inside the directory, so perimeter defenses do little once a delegated host is compromised. This is where identity governance and workload hardening converge. Practitioners should remove unconstrained delegation as a design default and use it only with explicit, reviewed exception handling.

Privilege sensitivity must extend to the propagation path, not just the principal. A sensitive account flag helps, but it does not solve the broader problem of identity material moving through a host that may be less trusted than the account itself. That is the core governance gap. Teams should reduce both who holds privilege and where that privilege can travel.

Identity propagation control: the real control objective is limiting where high-value Kerberos authority can be observed, stored, or reused. This concept captures the difference between account protection and path protection. The practitioner conclusion is to design around the propagation route, not only the endpoint account.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly identity risk is actually remediated.
  • Use 52 NHI Breaches Analysis to compare how identity abuse patterns translate into real intrusion paths and response gaps.

What this signals

Identity propagation control is the more useful lens for delegations than simple configuration hygiene. Teams that only audit whether a box is enabled miss the larger question of where privileged identity material can travel, be stored, and be reused. That matters because once a trusted host can observe tickets in memory, the control problem shifts from access approval to trust boundary design.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the broader lesson is that over-trust is the default failure mode in identity systems. Active Directory delegation is one expression of that pattern, and the same logic appears in service accounts, API keys, and workload credentials. Programmes that reduce standing trust will find delegation risks easier to govern.

For IAM roadmaps, the practical signal is to connect directory delegation review to PAM, Tier 0 segmentation, and incident detection around memory-resident credentials. If the programme still treats delegation as a point-in-time AD audit item, it will miss the operational value of continuous identity path monitoring.


For practitioners

  • Inventory all unconstrained delegation hosts Query Active Directory for computers and user accounts with unconstrained delegation enabled, then classify each host by business criticality and privilege adjacency. Any system that can observe ticket traffic for privileged users should enter your high-risk inventory immediately.
  • Remove unconstrained delegation by default Replace it with narrower delegation models or redesign the application flow so the service does not need reusable user authority. If removal is not yet feasible, require exception approval, compensating monitoring, and a scheduled retirement plan.
  • Treat delegation hosts as Tier 0 assets Place these systems under stronger segmentation, tighter admin controls, and more frequent review because a compromise can expose reusable ticket material in memory. Align access, logging, and response procedures with other Tier 0 systems.
  • Protect privileged accounts from delegation paths Enable the Account is sensitive and cannot be delegated setting for Tier 0 and other highly privileged accounts, and verify that the flag is enforced consistently across the directory. This reduces the chance that privileged tickets can be forwarded into risky trust paths.

Key takeaways

  • Unconstrained delegation is dangerous because it lets a compromised host reuse Kerberos authority, not just authenticate users.
  • A single exposed delegation server can turn a local compromise into broad domain impersonation and lateral movement.
  • The practical fix is to remove unconstrained delegation, protect privileged accounts from delegation paths, and treat remaining hosts as Tier 0 assets.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Delegation abuse expands the impact of stale or overbroad NHI trust paths.
NIST CSF 2.0PR.AC-4Delegation is an access control design issue with direct blast-radius implications.
NIST Zero Trust (SP 800-207)Unconstrained delegation conflicts with continuous trust minimisation in zero trust.

Review delegation settings and remove any NHI trust path that allows reusable authority outside intent.


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.
  • 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

Unconstrained delegation, Kerberos ticket reuse, and Tier 0 identity protection are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for Active Directory risk, it is worth exploring.

This post draws on content published by Semperis: Unconstrained Delegation Explained. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-02-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org