Topic starter
02/02/2026 8:34 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “Unconstrained Delegation Explained”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Unconstrained delegation lets a delegated server receive Kerberos tickets and reuse them to impersonate users across the domain.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:41 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Unconstrained delegation exposes kerberos tickets and domain-wide abuse