Kerberos delegation explained: unconstrained, constrained, and resource-based

Why delegation exists

A web application that reads a database as the signed-in user needs to act on that user’s behalf toward a second service. Kerberos delegation makes that possible. The risk is that a service trusted to delegate can impersonate users, and if that service is compromised, so are the identities it can impersonate.

There are three kinds, with very different risk.

The three types

Unconstrained delegation (TrustedForDelegation) means users who authenticate to the server send it a copy of their TGT, and the server can use it to reach any service as that user. If an administrator connects to such a server, their TGT sits in its memory. Domain controllers are configured this way by necessity; other machines should not be.

Constrained delegation (msDS-AllowedToDelegateTo) limits the server to a list of target SPNs. Resource-based constrained delegation (msDS-AllowedToActOnBehalfOfOtherIdentity) is set on the target resource and lists which accounts may delegate to it. RBCD is the most granular, but write access to that attribute on a computer object is itself a dangerous permission to watch.

Lab: inventory delegation

Query the lab domain for computers and users with each type configured. On a clean lab, only the DC should show unconstrained delegation. Set unconstrained delegation on the member server, rerun the query, then switch it to constrained delegation for a single SPN and confirm the change.

Mark your admin account “Account is sensitive and cannot be delegated” or add it to Protected Users, so its tickets are never delegated by any server.

Snippet

Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation | Select Name
Get-ADUser -Filter 'TrustedForDelegation -eq $true' | Select Name
Get-ADObject -Filter 'msDS-AllowedToDelegateTo -like "*"' -Properties msDS-AllowedToDelegateTo | Select Name, msDS-AllowedToDelegateTo
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' } | Select Name
Set-ADUser admin-me -AccountNotDelegated $true

Reduce the risk

Remove unconstrained delegation from every non-DC. Replace it with constrained delegation or RBCD to specific services. Put privileged accounts in Protected Users or set AccountNotDelegated. Monitor 5136 changes to the delegation attributes.

Disable the Print Spooler service on domain controllers and servers that do not print. Spooler has been used to coerce DCs into authenticating to an attacker-controlled host with unconstrained delegation.

Diagram

Delegation types by risk

From broadest to narrowest.

Unconstrained
Server receives users’ TGTs and can go anywhere as them. Only DCs.
Constrained
Server may delegate to a listed set of SPNs.
Resource-based
Target lists who may delegate to it. Watch write access to the attribute.
Sensitive accounts
AccountNotDelegated or Protected Users: never delegated.

Check yourself

1. Which delegation type causes users’ TGTs to be stored on the server?

2. How do you prevent an admin account’s credentials from ever being delegated?

3. Which attribute implements resource-based constrained delegation?