Kerberos delegation: three mechanisms, three ways to lose the domain
Kerberos delegation lets a service act on behalf of a user. Each of its three variants, when misconfigured, gives an attacker a way to impersonate an administrator. Spotting them is easy; fixing them takes method.
Why delegation exists
A user signs in to a web application that must query a database on their behalf. Kerberos delegation enables this "double hop": the front-end service acts for the user towards a second service. Useful — but every delegation mechanism hands a server part of the power of the users who connect to it. Poorly controlled, it becomes a path to domain admin.
Unconstrained delegation
The oldest and most dangerous. A server with unconstrained delegation receives a copy of the TGT — the master ticket — of every user who authenticates to it, and can use it towards any service. If a domain admin connects, their ticket stays in memory. Worse: coercion techniques can force a domain controller to authenticate to that server, handing over the domain controller's own ticket.
Only domain controllers should carry this setting. Any other server with it must be fixed first.
Constrained delegation
Here the server can only delegate to a defined list of services (the msDS-AllowedToDelegateTo attribute). Safer, with one important caveat: if protocol transition is allowed ("Use any authentication protocol"), the server can obtain a ticket as any user, without that user ever connecting. Whoever compromises the server can then impersonate an administrator to the target services — and the service name listed is not always the boundary people assume.
Resource-based constrained delegation
With RBCD, the target resource declares, in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which accounts may delegate to it. The risk lies in write rights: an attacker able to modify that attribute on a computer object can register an account they control, then gain admin access to that machine. And by default, any domain user can create up to ten computer accounts (ms-DS-MachineAccountQuota), which provides exactly the account they need.
Two simple protections for privileged accounts: tick "Account is sensitive and cannot be delegated", and add them to the Protected Users group. Their tickets will then not be delegated by any mechanism.
Action plan
- List accounts and computers with unconstrained delegation, excluding domain controllers, and move them to constrained delegation.
- Review constrained delegations with protocol transition and narrow their scope.
- Look for populated RBCD attributes and excessive write rights on computer objects.
- Set
ms-DS-MachineAccountQuotato zero and give domain join to a dedicated account. - Protect every admin account against delegation.
These checks belong in any serious Active Directory audit: they link a discreet technical setting to a very concrete attack path.