Kerberos delegation: unconstrained, constrained and resource-based

Delegation is the part of Kerberos that lets a service act as the user who called it. It is necessary, it is widely deployed, and one of its three forms is a standing invitation to domain compromise. The three are frequently discussed as if they were configuration variants of the same feature. They are not: they differ in who trusts whom, and in who is allowed to set it up.

The problem delegation exists to solve

A user opens a web application. The web server needs to read that user’s rows from a database on another host. The database must apply the user’s permissions, not the web server’s.

The web server has a Kerberos service ticket proving who the user is, but a service ticket is issued for one service. The web server cannot simply reuse it against the database. It needs to obtain a ticket to the database on behalf of the user. That is delegation, and the only real question is how tightly the directory constrains it.

Unconstrained delegation

The original model, present since Windows 2000. The computer or service account is marked “trusted for delegation” by setting TRUSTED_FOR_DELEGATION on the account.

When a user authenticates to a service with unconstrained delegation, the domain controller includes the user’s ticket-granting ticket inside the service ticket. The service extracts that TGT and caches it in memory. It can then request a ticket to any service in the forest, as that user.

Read that again, because the consequence is the whole point. A server with unconstrained delegation holds, in memory, a reusable credential for every user who has authenticated to it. Compromise that server and you can impersonate those users anywhere. If a domain administrator ever touches it — or if you can coerce a domain controller into authenticating to it — you have the directory.

There is essentially no modern reason to keep it. Find it and remove it:

Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName

Get-ADUser -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation |
    Select-Object Name, DistinguishedName

Domain controllers will appear in that first result. That is expected and correct — they are trusted for delegation by design. Everything else on the list needs a justification or a migration to one of the constrained models.

Two protections matter alongside removal. Marking privileged accounts as “Account is sensitive and cannot be delegated” prevents their TGT being forwarded at all, and membership of the Protected Users group achieves the same thing along with several other restrictions. Apply one of them to every Tier 0 account regardless of how confident you are that unconstrained delegation is gone.

Constrained delegation

Introduced in Windows Server 2003. The account is restricted to a named list of service principal names it may request tickets for, held in msDS-AllowedToDelegateTo. The web server can obtain a ticket to the specific database service and nothing else.

This is a genuine improvement: compromise of the web server no longer yields arbitrary impersonation across the forest, only impersonation to the listed services.

It has two structural weaknesses.

Configuration is a privileged operation. The msDS-AllowedToDelegateTo attribute sits on the front-end account, and writing it requires the SeEnableDelegationPrivilege right — in practice, a domain administrator. The team that owns the resource has no say. Every delegation request becomes a Tier 0 change, which is both a bottleneck and a reason people ask for unconstrained instead.

It does not cross domain or forest boundaries. The front-end and the target must be in the same domain.

There is also a variant worth knowing: constrained delegation with protocol transition, configured as “use any authentication protocol”. This allows the service to obtain a ticket for a user who never authenticated to it with Kerberos at all. It is more powerful and correspondingly more dangerous than “use Kerberos only”, and it is worth auditing separately:

# An LDAP filter, because the attribute name contains a hyphen and will not
# parse inside a script-block -Filter.
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
    -Properties 'msDS-AllowedToDelegateTo', 'TrustedToAuthForDelegation' |
    Format-List Name, TrustedToAuthForDelegation, 'msDS-AllowedToDelegateTo'

TrustedToAuthForDelegation being true is protocol transition.

Resource-based constrained delegation

Introduced in Windows Server 2012, and the model to prefer. It inverts the direction of trust.

Instead of the front-end account listing what it may delegate to, the resource lists which principals may delegate to it. The list lives on the target account in msDS-AllowedToActOnBehalfOfOtherIdentity, which holds a security descriptor rather than a list of service principal names.

Two consequences follow, and both are improvements:

• The resource owner configures it. Whoever can write to the target computer object can permit delegation to it. No domain administrator is required, which removes the Tier 0 bottleneck that pushed people toward unconstrained delegation.
• It works across domains and forests, because the check happens at the resource.

Configuration is a single cmdlet on the target:

# Allow the front-end server to obtain tickets to this resource on behalf of users.
$frontEnd = Get-ADComputer -Identity WEB01
Set-ADComputer -Identity APP01 -PrincipalsAllowedToDelegateToAccount $frontEnd

# Confirm what is currently permitted.
Get-ADComputer -Identity APP01 -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount

To remove it, set the same parameter to $null. Cached tickets mean the change is not always immediate on hosts that already hold one; expect to wait out the ticket lifetime or purge tickets on the front end when testing.

The same parameter exists on Set-ADUser and Set-ADServiceAccount for service accounts, and on the corresponding New-* cmdlets.

Comparing the three honestly

	Unconstrained	Constrained	Resource-based
Attribute	userAccountControl flag	msDS-AllowedToDelegateTo	msDS-AllowedToActOnBehalfOfOtherIdentity
Held on	Front end	Front end	Resource
Scope of impersonation	Any service, any user	Listed services	Listed principals, to this resource
Who configures	Domain admin	Domain admin	Resource owner
Crosses domains	No	No	Yes
Blast radius if front end is compromised	The forest	The listed services	This resource

Implementation considerations

Resource-based delegation is still delegation. Write access to a computer object becomes the ability to permit impersonation to that computer. Anyone who can create computer objects, or who holds write access through an over-broad delegation, can configure this. Audit who can write to computer objects, and review the default ms-DS-MachineAccountQuota, which historically allows ordinary users to create computer accounts.

Migrate, do not accumulate. Replacing unconstrained delegation on a server usually means identifying every service it legitimately reaches. Capture that from real traffic before the change rather than from a design document, and make the change in a window where a failure is visible.

Service principal names are still the hard part. Most delegation faults that reach me are not delegation faults. They are duplicate or missing service principal names, or a service account changed without the SPN moving with it. setspn -X finds duplicates, and a duplicate SPN breaks Kerberos for that service regardless of how delegation is configured.

Monitor for reintroduction. Unconstrained delegation tends to come back, because it is what a vendor installation guide asks for. Run the audit query above on a schedule and alert on anything new. Microsoft Defender for Identity reports it as a posture assessment if you have it.

Where this stops

This article covers what each model does and how it is configured. It does not cover building a delegation design for a specific application, protocol transition edge cases, or the constrained delegation behaviour of Microsoft Entra Domain Services, which is managed differently from a self-run forest.

Delegation also interacts directly with the account separation described in administrative tiering. Removing unconstrained delegation and marking privileged accounts as sensitive are the two changes I would make before almost anything else in that programme.

Verification and limits

Attribute names, cmdlet parameters, version requirements and the direction of trust for each model were checked against current Microsoft documentation on 20 September 2026.

The commands here were not executed in a lab for this article. The read-only queries are safe to run. Set-ADComputer -PrincipalsAllowedToDelegateToAccount and any removal of existing delegation will break a working application if the dependency was not mapped first, so record the current attribute value before changing it and test in a non-production forest.

References

• Kerberos constrained delegation overview
• Troubleshooting Kerberos resource-based constrained delegation
• Making the second hop in PowerShell remoting
• Unconstrained Kerberos delegation security assessment