RBCD Explained: Resource-Based Constrained Delegation
Resource-Based Constrained Delegation from the ground up: where the config lives, why write access to the target matters, and S4U2Self with S4U2Proxy.
RBCD gets easier once you reduce it to one question: which service does the final resource trust to represent users?
Resource-Based Constrained Delegation moves that decision to the resource side.
Instead of configuring the front-end with a list of services it may delegate to, the destination object stores which principals may act on behalf of users when accessing that resource.
For a pentester, that becomes powerful when a low-privileged account can modify the destination object.
The examples below assume a lab or an authorized penetration test.
Where the configuration lives
RBCD uses this attribute:
1
msDS-AllowedToActOnBehalfOfOtherIdentity
The attribute lives on the object representing the resource.
If the target is WEB01$, the relevant configuration is stored on WEB01$.
It contains a security descriptor defining which principals may use resource-based delegation against that object.
The offensive path appears when a controlled account can change it.
The chain needs a controlled principal
RBCD abuse normally needs a principal the KDC recognizes as a service.
A computer account works well because it has SPNs.
If the domain still allows regular users to create computers through MachineAccountQuota, a controlled machine account can be created for a lab test.
Example:
1
2
3
4
5
impacket-addcomputer \
-computer-name 'ATTACK01$' \
-computer-pass 'TempMachine2026!' \
-dc-ip 10.10.10.10 \
'lab.local/gabriel:Password123!'
This step depends on domain configuration.
If MachineAccountQuota is zero, another controlled principal with the required properties is needed.
Write access to the target is the critical piece
Assume gabriel has GenericWrite over WEB01$.
The account may be able to modify the computer’s RBCD attribute.
The goal is effectively:
1
WEB01$ trusts ATTACK01$ as a delegator
After that, the KDC may issue tickets on behalf of another user according to the protocol rules.
S4U2Self and S4U2Proxy sit in the middle
Two Kerberos mechanisms explain the flow.
S4U2Self lets a service obtain a ticket to itself while representing a user.
S4U2Proxy lets that service exchange the context for a ticket to an authorized back-end service.
RBCD controls whether the resource accepts that path from the delegating principal.
The offensive sequence often looks like this:
1
2
3
4
5
6
7
8
9
ATTACK01$
|
| S4U2Self
v
impersonated user
|
| S4U2Proxy
v
cifs/WEB01
The final ticket is specific to the requested SPN.
That matters because Kerberos delegation works with services rather than a generic concept of administrative access to the host.
An Impacket example
After configuring the RBCD relationship, a lab test may request a ticket like this:
1
2
3
4
5
impacket-getST \
-spn 'cifs/WEB01.lab.local' \
-impersonate 'Administrator' \
-dc-ip 10.10.10.10 \
'lab.local/ATTACK01$:TempMachine2026!'
If the KDC accepts the flow, a Kerberos credential cache is written.
Then:
1
export KRB5CCNAME=Administrator@cifs_WEB01.lab.local@LAB.LOCAL.ccache
The next validation step needs to use the service and protocol for which the ticket was issued.
DNS needs to be correct too.
The target can be a user or computer
RBCD is not limited to computer accounts.
A resource can also be represented by a service account.
The reasoning stays similar.
Find the object representing the service.
Find who can edit delegation on it.
Find a controlled principal that can be authorized.
Then follow the tickets.
Why GenericWrite over a computer matters
A computer object carries several security-sensitive attributes.
If an account can write to the object, RBCD may become one route.
Shadow Credentials may become another.
SPNs and other properties also matter depending on the exact rights granted.
That is why a GenericWrite edge toward a computer account deserves careful analysis.
MachineAccountQuota became a habit in old walkthroughs
For years, many examples assumed ms-DS-MachineAccountQuota was 10.
That value can let authenticated users create a limited number of computer accounts unless other controls prevent it.
Hardened environments often change it.
I check the value before planning the chain.
RBCD still exists when MAQ is zero.
You simply need another controlled service principal.
Cleanup needs to be exact
RBCD changes directory state.
After the proof, remove the entry added to the attribute.
If a machine account was created only for testing, remove it according to the agreed scope.
Confirm the final security descriptor.
Do not rely only on a tool saying cleanup succeeded.
Detection and remediation
Changes to msDS-AllowedToActOnBehalfOfOtherIdentity deserve auditing.
Teams should also review who has GenericAll, GenericWrite, WriteDACL, or equivalent rights over computer and service accounts.
Reducing MachineAccountQuota removes one convenience used by many offensive paths.
It does not fix an ACL that allows the resource object to be changed.
The central remediation is protecting the object that decides who can delegate.
The useful way to remember RBCD
The final resource stores the list of principals allowed to represent users to it.
If an attacker can modify that list and controls a suitable principal, the KDC may issue the ticket that completes the path.
The SPN defines where the ticket works
After delegation succeeds, there is still a difference between controlling a host and holding a ticket for one specific service.
A ticket for cifs/WEB01 was created for CIFS.
If the real objective uses HTTP, LDAP or another service class, I validate which SPN needs to be requested and whether the account representing the host backs that service.
This prevents the vague conclusion that RBCD delivered “the entire machine” when the proof covered one service.
An existing computer account works too
MachineAccountQuota appears constantly because it makes a controlled principal with SPNs easy to create.
It is not the only route.
If the pentester already controls the password, hash or key for a computer account, that principal can serve the same purpose in many scenarios.
A service account with the right SPN may also work.
The useful question is whether you control a principal the KDC can treat as a service.
Forwardable tickets and S4U details matter
Delegation depends on Kerberos flags and rules that change with the scenario.
An account marked as sensitive for delegation may block impersonation.
Protected Users can change the available flow too.
Tools hide these details when everything works. When it fails, they become the troubleshooting path.
I read the KDC error, inspect ticket flags and verify the impersonated user’s configuration before blaming the RBCD ACL.
References
Microsoft Learn, Kerberos Constrained Delegation Overview.
Microsoft Learn, Configure resource-based Kerberos constrained delegation.
Fortra Impacket, Impacket.