Delegation is a legitimate Kerberos feature that lets a service act on a user's behalf when talking to a second service — the mechanism that makes "single sign-on all the way through" work. A web app that needs to reach a database as the logged-in user uses delegation to do it. That same impersonation power, when misconfigured, becomes one of the richest privilege-escalation surfaces in Active Directory. There are three flavours, and each is abused differently.
Why delegation exists
Imagine a user authenticates to a front-end web server, and that server needs to fetch the user's records from a back-end database — enforcing the user's own permissions, not the web server's. The web server needs to present the user's identity to the database. Delegation is the controlled way to let the front-end request a ticket to the back-end on the user's behalf.
The security question is always the same: how tightly is that impersonation scoped? The three delegation types are three answers, from dangerously broad to relatively narrow.
Unconstrained delegation
The original, and the most dangerous. A host trusted for unconstrained delegation is allowed to impersonate a user to any service. The mechanism: when a user authenticates to such a host, their TGT is sent along and cached in the host's memory. With the user's TGT in hand, the host can request tickets to anything as that user.
The abuse follows immediately. If you compromise a host trusted for unconstrained delegation, you get every TGT cached on it. And you do not have to wait for a valuable user to log in — you coerce one, ideally a domain controller, into authenticating to your host. The DC's TGT lands in your cache, and a DC's TGT is effectively the domain.
The flag TRUSTED_FOR_DELEGATION on any computer you can compromise is
close to game over. Domain controllers have it by design; the danger is when an
ordinary server has it too, because that server becomes a stepping stone to the
DC's identity.
Constrained delegation
Microsoft's response to how dangerous unconstrained delegation is.
Constrained delegation limits a service to impersonating users
only to a specific list of target services, named in the account's
msDS-AllowedToDelegateTo attribute. It also introduces
protocol transition (S4U2Self), which lets the service obtain a
ticket to itself as any user, even one who never actually authenticated.
The abuse turns on two extensions:
| Extension | What it does |
|---|---|
| S4U2Self | Lets the service request a ticket to itself as any chosen user — including Administrator |
| S4U2Proxy | Lets the service use that ticket to request a ticket to a delegated target service, as that user |
So if you compromise an account configured for constrained delegation, you can
impersonate any user (via S4U2Self) to the allowed target services (via
S4U2Proxy). If a delegated target is something like cifs/dc01, you can
reach that service as Administrator.
A subtlety worth knowing: the target service name in S4U2Proxy is not strongly bound to a single service class, so obtaining a ticket for one SPN on a host often lets you talk to other services on that same host. Constrained is safer than unconstrained, but "constrained to a domain controller service" is still a full compromise path.
Resource-based constrained delegation (RBCD)
The modern variant, and the one that appears constantly in attack chains because it
can be set up by the attacker. With classic constrained delegation, the
config lives on the impersonating account and requires privilege to change. RBCD
flips the direction: the resource (the target) decides who is allowed to
delegate to it, via its msDS-AllowedToActOnBehalfOfOtherIdentity
attribute.
That means if you have write access to a computer object, you can point its RBCD attribute at an account you control, and then impersonate any user to that computer. Write access to a computer object is common — via an ACL, or via a relayed LDAP session.
| Step | Action |
|---|---|
| 1. Control an account with an SPN | Create a computer account (any user can, by default, create up to 10) or use one you own |
| 2. Write the RBCD attribute | Set msDS-AllowedToActOnBehalfOfOtherIdentity on the target to your account |
| 3. Impersonate | Use S4U2Self + S4U2Proxy to get a ticket to the target as Administrator |
Each of these three abuses — capturing TGTs from an unconstrained host, S4U impersonation via constrained delegation, and writing an RBCD attribute you control — has its full command walkthrough in the Vulns & Misconfigs section under Unconstrained, Constrained, and RBCD. This page is the shared mechanism they all bend.
Comparison
| Type | Scope of impersonation | Attacker angle |
|---|---|---|
| Unconstrained | Any service, any user who authenticates to the host | Compromise the host, coerce a DC, capture its TGT |
| Constrained | Specific target services, but any user | Compromise the delegating account, impersonate Administrator to the targets |
| RBCD | Decided by the target resource | Gain write on the target, point it at an account you control |
Detection and defence
- Eliminate unconstrained delegation wherever it is not strictly required, and never on anything but DCs. Mark sensitive accounts "not delegatable" (the
NOT_DELEGATEDflag / Protected Users group). - Audit delegation attributes —
msDS-AllowedToDelegateToandmsDS-AllowedToActOnBehalfOfOtherIdentity— regularly; unexpected values are findings. - Restrict who can create computer accounts. The default
MachineAccountQuotaof 10 is what makes the RBCD chain trivial; set it to 0. - Put Tier-0 accounts in Protected Users so they cannot be delegated at all.
- Enforce LDAP signing/channel binding to close the relay route into RBCD setup.
The takeaway
Delegation is impersonation with a scope dial. Unconstrained sets the dial to "everything" and turns any compromised delegation host into a route to the DC's own identity. Constrained narrows the targets but still lets you impersonate anyone to them. RBCD moves the control onto the resource, which is exactly why attackers love it — write access to a computer object is enough to grant yourself impersonation. BloodHound surfaces all three, and the abuse tools (getST, bloodyAD, krbrelayx, ntlmrelayx) are in theToolkit Vulns & Misconfigs. The ticket mechanics behind S4U are on the Kerberos page.