Resource-based constrained delegation, explained

Resource-based constrained delegation (RBCD) is a legitimate Kerberos feature that appears in a surprising number of internal penetration test findings. Used as intended, it lets a server act on a user’s behalf when talking to another server. Misconfigured or abused, it gives an attacker administrator access to that server.

Delegation in one minute

Kerberos delegation solves a common problem: a front-end service (say, a web application) needs to access a back-end service (say, a database or file share) as the user, not as itself. Active Directory has three flavours:

Type	Configured on	Risk
Unconstrained	The front-end server	Very high: the server receives users’ full tickets
Constrained	The front-end server	Medium: limited to named back-end services
Resource-based constrained	The back-end resource	Depends on who can edit it

RBCD flips the model. Instead of a domain administrator telling the front-end what it may access, the back-end resource lists who is allowed to delegate to it. That list lives in an attribute on the back-end computer object called msDS-AllowedToActOnBehalfOfOtherIdentity.

Why it gets abused

The flip is what makes RBCD attractive to attackers. To configure classic constrained delegation you need high privileges. To configure RBCD you only need permission to write that one attribute on the target computer object.

So the attack pattern looks like this, at a high level:

1. The attacker controls an account with a service principal name. Often this is a computer account they created themselves, because by default any user can create up to ten. (See abusing computer accounts in Active Directory.)
2. They gain the ability to write to the target server’s delegation attribute. This might come from overly broad permissions, a misconfigured group, or by relaying an authentication from that server to LDAP.
3. They add their account to the target’s list of allowed delegators.
4. Using standard Kerberos extensions (S4U2Self and S4U2Proxy), their account requests a service ticket to the target as an administrator, and Kerberos issues it, because the target said that account was trusted to delegate.

The result is administrative access to the target server, without knowing any administrator’s password.

Where we usually find it

In internal tests, RBCD abuse tends to come from three root causes:

• Write permissions on computer objects granted to helpdesk or deployment groups, or inherited from organisational units.
• NTLM relay to LDAP where LDAP signing and channel binding are not enforced. An attacker who can coerce a server to authenticate can relay that authentication and edit the server’s own delegation attribute.
• The default machine account quota of 10, which provides the attacker-controlled account the attack needs.

How to prevent it

Control	Why it helps
Set ms-DS-MachineAccountQuota to 0	Removes the easiest source of an attacker-controlled account with an SPN
Enforce LDAP signing and LDAP channel binding on domain controllers	Stops relayed authentication from modifying directory objects
Remove unneeded write permissions on computer objects	Removes the ability to set the delegation attribute
Mark privileged accounts “Account is sensitive and cannot be delegated”, or add them to the Protected Users group	Kerberos won’t issue delegated tickets for those accounts, so the attacker can’t impersonate them
Disable NTLM where possible, and require SMB signing	Reduces coercion and relay opportunities

Note that “cannot be delegated” protects the accounts you apply it to. An attacker can still impersonate any other privileged account that lacks it, so apply it to every administrative account.

How to detect it

• Event 5136 on domain controllers when msDS-AllowedToActOnBehalfOfOtherIdentity changes. Legitimate changes to this attribute are rare, so any change deserves a look.
• Event 4741 for new computer accounts created by non-administrators.
• Kerberos service ticket requests using S4U extensions from accounts that don’t normally perform delegation.

Regularly listing which computer objects have this attribute set at all is a useful quick check. In most environments the answer should be “very few, all documented”.

The takeaway

RBCD is not a vulnerability in itself. It becomes one when three ordinary settings line up: users can create computer accounts, someone can write to a server’s delegation attribute, and LDAP relay isn’t blocked. Fix any one of them and the chain breaks; fix all three and it’s gone. An internal penetration test shows whether that chain exists in your network today.