Kerberos Delegation: Unconstrained, Constrained, RBCD
The three Kerberos delegation models compared: what each one trusts, how to enumerate them and what to look for in each during a pentest.
Delegation exists because real applications sometimes need to act on behalf of users.
A front-end authenticates the person.
Then it needs to access a database, file server, or API using that user’s identity.
Kerberos solves that problem through delegation.
Risk appears when the trust is broader than the application actually needs.
The examples below assume a lab or an authorized penetration test.
Unconstrained Delegation came first
Unconstrained Delegation allows a service to delegate a user’s identity to other services.
Its defining characteristic is broad reach.
In classic Windows environments, a server configured this way may receive enough Kerberos material to act on behalf of users who authenticate to it.
If a privileged identity authenticates to a compromised host with Unconstrained Delegation, the impact can grow quickly.
That is why Microsoft recommends more restricted models when possible.
The real problem is the size of the trust
Think about a web server.
A user authenticates to the front-end.
The server only needs to access one database.
If the front-end account can represent that user to any service in the domain, the trust exceeds the requirement.
Compromise of the front-end inherits that excess.
Constrained delegation was designed to reduce this problem.
Constrained Delegation limits the destination
With Kerberos Constrained Delegation, the front-end receives a list of services it may delegate to.
Conceptually:
1
2
3
4
5
WEB01
|
| may delegate to
v
MSSQLSvc/SQL01.lab.local:1433
The trust now has a defined destination.
Traditional KCD stores that configuration on the delegating account.
The front-end effectively says:
1
I may represent users to these services.
That sharply reduces the reach compared with unconstrained delegation.
Protocol Transition adds another piece
Some services authenticate users through a mechanism other than Kerberos.
They may still need to access a backend through Kerberos on behalf of that user.
S4U2Self lets a service obtain a ticket to itself while representing a user.
S4U2Proxy lets it request a ticket to an authorized backend.
The historical TrustedToAuthForDelegation flag participates in traditional constrained delegation when protocol transition is required.
Those names appear constantly in tooling.
The useful mental model is the sequence.
A service receives or asserts a user identity.
Then the KDC decides whether that identity may be carried to another SPN.
RBCD moves the decision to the resource
Resource-Based Constrained Delegation changes where the trust is stored.
The backend now defines which principals may represent users to it.
The configuration lives on the resource in msDS-AllowedToActOnBehalfOfOtherIdentity.
Conceptually:
1
SQL01 trusts WEB01 as a delegator
This model helps with cross-domain scenarios and lets the resource administrator control the relationship.
For offensive testing, that creates a major difference.
If you can modify the destination object, you may be able to change who the resource trusts for delegation.
Comparing the three models
Unconstrained delegation places little restriction on destination.
Constrained delegation limits the front-end to specific SPNs.
RBCD stores the accepted delegators on the final resource.
The user still moves through Kerberos.
The location of the trust changes.
That is the difference you need to identify in BloodHound and LDAP.
How I enumerate
With RSAT PowerShell:
1
Get-ADComputer -Filter * -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo,PrincipalsAllowedToDelegateToAccount
For service accounts:
1
Get-ADUser -Filter * -Properties TrustedForDelegation,TrustedToAuthForDelegation,msDS-AllowedToDelegateTo,PrincipalsAllowedToDelegateToAccount
In large environments, BloodHound makes relationships much easier to inspect.
I use direct enumeration to confirm what the graph suggested.
What I look for in Unconstrained Delegation
First I identify hosts and accounts configured that way.
Then I ask which users actually authenticate to them.
An old application server receiving administrator logons may be far more dangerous than one isolated in a technical segment.
The configuration shows exposure.
The authentication flow shows impact.
What I look for in Constrained Delegation
Here I read the allowed SPNs.
Delegation to:
1
cifs/FILE01
creates a different path from:
1
MSSQLSvc/SQL01:1433
The service ticket is specific.
Techniques involving service substitution may matter depending on SPN and account configuration.
I avoid turning every KCD relationship into a claim of full host compromise without validating the reachable service.
What I look for in RBCD
RBCD makes me inspect the resource ACL.
Who can write to the computer account?
Who can modify the delegation security descriptor?
Is there a controllable principal with an SPN?
Does the destination expose a useful service?
That sequence connects ACL abuse with Kerberos.
It is why RBCD appears so often in modern attack paths.
Sensitive accounts can change the result
Active Directory includes protections that restrict delegation for certain identities.
Accounts marked “Account is sensitive and cannot be delegated” also change behavior.
The existence of a delegation relationship does not guarantee that every user can be impersonated.
Validate with an identity that actually fits the scenario.
Delegation is an architecture problem
Sometimes the pentest finds a legitimate configuration.
The front-end truly needs to access the backend on behalf of users.
The recommendation should focus on reducing scope.
Replace unconstrained delegation with a restricted model.
Limit SPNs.
Protect the resource ACL.
Keep administrative identities away from systems that receive delegable credentials.
Monitor changes to delegation attributes.
A mental model that works
Unconstrained asks very little about destination.
Constrained lets the front-end define a restricted list.
RBCD lets the backend define who may arrive.
Once you know where the trust is stored, it becomes much easier to identify which permission would need to be compromised to alter the chain.
Delegation can live on user objects too
A service account is often an Active Directory user object.
Searching only computer accounts therefore leaves a gap.
Older applications frequently run under traditional domain accounts and register SPNs on those identities.
If that account has constrained or unconstrained delegation, the path exists even without a computer object configured the same way.
I enumerate both principal types.
A compromised front-end changes the whole trust relationship
Delegation exists so a front-end can carry user identity toward a backend.
Once the front-end is compromised, the attacker occupies the delegated principal’s position.
The next questions are which users authenticate through it and which services it can reach on their behalf.
That is why a technically legitimate configuration can still create high architectural risk on a highly exposed server.
Service class belongs in validation
An SPN such as MSSQLSvc/SQL01:1433 represents a specific service.
The delegation path should be validated against the service class required by the objective.
Generalizing an MSSQL ticket into “control of SQL01” may overstate impact.
I prove the reachable service and expand the conclusion only when another technical relationship supports it.
References
Microsoft Learn, Kerberos Constrained Delegation Overview.
Microsoft Learn, Kerberos authentication troubleshooting guidance.
Microsoft Learn, Windows Authentication Concepts.