Resource-Based Constrained Delegation in Active Directory

Resource-Based Constrained Delegation, often shortened to RBCD, is a Kerberos delegation model in Active Directory where the target resource controls which accounts are allowed to delegate to it. It was introduced to make delegation easier to manage across service boundaries, but it can create serious security risk when permissions on computer objects are weak or misconfigured. In simplest terms, RBCD is the resource decides who is allowed to act on behalf of users to that resource.

That is different from traditional constrained delegation, where delegation is configured on the account that performs the delegation. With RBCD, the delegation permission is configured on the target computer or service account itself.

What is Kerberos delegation?

Kerberos delegation allows a service to access another service on behalf of a user.

This is common in multi-tier applications. For example:

A user accesses a web application.
The web application needs to query a backend service.
The backend service should receive the request in the context of the user.
Kerberos delegation allows the front-end service to access the backend service on behalf of that user.

Delegation is not automatically bad. It becomes risky when it is too broad, poorly controlled, undocumented, or configured on systems where attackers can modify delegation-related attributes.

What is Resource-Based Constrained Delegation?

Resource-Based Constrained Delegation is a form of Kerberos constrained delegation where the resource being accessed stores the delegation permission.

The key Active Directory attribute is msDS-AllowedToActOnBehalfOfOtherIdentity

Microsoft describes this attribute as being used for access checks to determine whether a requestor has permission to act on behalf of other identities to services running as the account. In practical terms, if a computer object allows another account in this attribute, that allowed account may be able to impersonate users to services running on the target computer.

For example:

APP01 allows WEB01 to act on behalf of users to APP01.

That means WEB01 may be able to obtain delegated access to services on APP01 on behalf of users.

RBCD vs traditional constrained delegation

Traditional constrained delegation and RBCD both limit delegation to specific resources, but the control model is different.

Delegation type	Where delegation is configured	Who controls it	Common attribute
Constrained delegation	Delegating account	Domain administrators or delegated admins	msDS-AllowedToDelegateTo
Resource-Based Constrained Delegation	Target resource	The resource owner or anyone with rights to modify the target object	msDS-AllowedToActOnBehalfOfOtherIdentity

Traditional constrained delegation answers where is this account allowed to delegate. However, RBCD answers who is allowed to delegate to this resource.

Microsoft’s Kerberos constrained delegation overview notes that traditional constrained delegation requires domain administrator privileges to configure a domain account for a service and is limited to a single domain, while newer constrained delegation capabilities support resource-based control.

Why RBCD matters

RBCD matters because control over the target object becomes extremely important.

If an attacker can modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer object, they may be able to grant another account the ability to impersonate users to that computer. That can become a major privilege escalation path.

Risk increases when:

Computer objects have weak access control lists.
Non-admin users can modify computer object attributes.
Help desk or service accounts have excessive rights.
MachineAccountQuota allows users to create computer accounts.
Attackers compromise an account with write access to a computer object.
RBCD settings are not monitored or reviewed.
Tier 0 systems have weak object permissions.

RBCD is especially important because the risky condition may not be obvious from normal group membership alone. The issue often lives in object-level permissions and delegation attributes.

How attackers abuse RBCD

A typical RBCD abuse path looks like this:

An attacker compromises a domain account.
The attacker finds a computer object where they have write permissions.
The attacker controls or creates another computer account.
The attacker modifies the target computer’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
The attacker configures the controlled account as allowed to act on behalf of users to the target.
The attacker requests Kerberos tickets that allow impersonation to the target computer.
The attacker accesses services on the target as another user.

The exact impact depends on the target computer and what services are available. If the target is a normal workstation, the impact may be limited. If the target is a server, domain controller, management system, or Tier 0 asset, the impact can be severe.

MITRE ATT&CK tracks Kerberos ticket theft and abuse under Steal or Forge Kerberos Tickets, T1558, which is relevant to understanding how delegated Kerberos access can support lateral movement and privilege escalation.

Why computer object permissions are important

RBCD abuse often depends on permissions to modify the target computer object.

Important permissions include:

GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty
Validated write permissions
Rights to modify msDS-AllowedToActOnBehalfOfOtherIdentity

If a user or service account can modify sensitive attributes on a computer object, that account may be able to introduce delegation risk. This is why Active Directory object permissions matter. A user may not be a local administrator, Domain Admin, or member of a privileged group, but they may still have dangerous rights over specific computer objects.

MachineAccountQuota and RBCD

MachineAccountQuota is another setting that often appears in RBCD discussions.

By default, Active Directory has historically allowed authenticated users to join a limited number of computers to the domain. This is controlled by the domain attribute ms-DS-MachineAccountQuota

If ordinary users can create computer accounts, and an attacker also has write access to a target computer object, the attacker may be able to create or control a computer account and use it in an RBCD abuse path. MachineAccountQuota by itself is not the same as RBCD, but it can make RBCD abuse easier in some scenarios.

PowerShell: Check MachineAccountQuota

You can review the current MachineAccountQuota value with:

Get-ADDomain | Select-Object DistinguishedName, ms-DS-MachineAccountQuota

A value greater than zero means non-privileged authenticated users may be able to create computer accounts up to the configured limit, depending on other controls and environment behavior. Many organizations reduce this value to 0. However, before changing it, confirm whether any legitimate provisioning workflows depend on non-admin computer account creation.

PowerShell: Find objects with RBCD configured

The primary attribute to review is msDS-AllowedToActOnBehalfOfOtherIdentity.

To find computer accounts with RBCD configured:

Get-ADComputer -Filter * `
    -Properties msDS-AllowedToActOnBehalfOfOtherIdentity, OperatingSystem, LastLogonDate |
    Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null } |
    Select-Object Name, DNSHostName, OperatingSystem, LastLogonDate, DistinguishedName

This identifies computer objects where the RBCD attribute is populated.

PowerShell: Find user accounts with RBCD configured

RBCD is most commonly discussed on computer objects, but the attribute can exist on other account objects as well.

Get-ADUser -Filter * `
    -Properties msDS-AllowedToActOnBehalfOfOtherIdentity, Enabled, PasswordLastSet, LastLogonDate |
    Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null } |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, DistinguishedName

Any account with this attribute populated should be reviewed.

PowerShell: Review the raw RBCD security descriptor

The RBCD attribute stores a security descriptor. Reading and interpreting it directly can be more complex than reviewing a simple string attribute.

This command can help show whether the attribute is populated:

Get-ADObject -LDAPFilter "(msDS-AllowedToActOnBehalfOfOtherIdentity=*)" `
    -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
    Select-Object Name, ObjectClass, DistinguishedName

For deeper review, defenders often use specialized tooling or scripts to parse the security descriptor and identify which principals are allowed to act on behalf of other identities.

PowerShell: Find computer objects with risky delegated permissions

RBCD abuse often begins with write access to a computer object. A full ACL review is more involved, but you can start by reviewing ACLs on sensitive computer objects.

Example for one computer:

$Computer = Get-ADComputer "APP01" -Properties DistinguishedName
$Acl = Get-Acl "AD:\$($Computer.DistinguishedName)"

$Acl.Access |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, ObjectType, IsInherited |
    Sort-Object IdentityReference

Look for unexpected users or groups with rights such as:

GenericAll
GenericWrite
WriteDacl
WriteOwner
WriteProperty

This should be performed carefully, especially for servers, domain controllers, management systems, and other high-value assets.

GUI: How to check RBCD

RBCD is not as easy to review in the GUI as traditional delegation settings. The standard Delegation tab in Active Directory Users and Computers does not provide the same clear view for RBCD.

A basic GUI review can still help:

Open Active Directory Users and Computers.
Enable Advanced Features from the View menu.
Find the target computer object.
Open Properties.
Review the Security tab.
Click Advanced.
Review users and groups with write-level permissions over the object.

This does not fully decode the RBCD attribute, but it helps identify whether unexpected principals can modify the computer object.

For RBCD-specific review, PowerShell or security tooling is usually more effective.

How to remediate risky RBCD

The right remediation depends on whether the RBCD configuration is legitimate.

If RBCD is not required

Remove the RBCD configuration from the target object.

Because msDS-AllowedToActOnBehalfOfOtherIdentity contains a security descriptor, do not clear it blindly unless you understand the dependency and have confirmed it is not needed.

A basic removal command may look like this:

Set-ADComputer -Identity "APP01" -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

Use this carefully and test first.

If RBCD is required

Keep the configuration as narrow as possible.

Review:

Which principal is allowed to delegate to the resource
Whether the principal is still required
Whether the target resource is sensitive
Whether the delegating account is overprivileged
Who can modify the target computer object
Whether the configuration is documented
Whether changes are monitored

If object permissions are the problem

Remove unnecessary write permissions from computer objects.

Focus especially on:

Tier 0 systems
Domain controllers
Management servers
Certificate authorities
Identity infrastructure
Backup infrastructure
Security tooling servers
Servers where privileged users authenticate

RBCD is often a symptom of a broader object permission problem.

Reduce MachineAccountQuota where appropriate

Review whether ordinary users need the ability to create computer accounts.

If not, consider setting MachineAccountQuota to zero:

Set-ADDomain -Identity (Get-ADDomain).DistinguishedName -Replace @{"ms-DS-MachineAccountQuota"=0}

Test this change first if your organization has automated provisioning, imaging, help desk, or domain join workflows that rely on the default behavior.

Protect privileged accounts from delegation

Privileged accounts should generally be protected from delegation.

In Active Directory Users and Computers, enable Account is sensitive and cannot be delegated

This helps prevent the account from being delegated to services.

Consider this protection for:

Domain Admin accounts
Enterprise Admin accounts
Schema Admin accounts
Tier 0 administrator accounts
Highly privileged service accounts
Sensitive operational accounts

Also consider using the Protected Users group for appropriate privileged accounts after testing compatibility.

Detection opportunities

Detection should include both configuration monitoring and behavior monitoring.

Configuration monitoring

Watch for changes to:

msDS-AllowedToActOnBehalfOfOtherIdentity
Computer object ACLs
Computer account creation
ms-DS-MachineAccountQuota
userAccountControl
Service Principal Names
Ownership changes on computer objects
Delegation-related permissions

Useful Windows Security events include:

Event ID	Purpose
4741	A computer account was created
4742	A computer account was changed
5136	A directory service object was modified
4670	Permissions on an object were changed
4769	A Kerberos service ticket was requested

Event ID 5136 can be especially useful when directory service change auditing is enabled and configured to capture modifications to sensitive attributes.

Behavioral monitoring

Look for:

New or unexpected computer accounts
Computer object changes followed by Kerberos activity
RBCD attribute changes on sensitive systems
Service ticket requests from unusual hosts
Delegation-related changes made by non-admin users
Authentication to sensitive services using unexpected accounts
Privileged users authenticating to systems with delegation exposure

A single event may not prove abuse. The value comes from correlating object changes, computer account creation, Kerberos ticket activity, and administrative behavior.

Common mistakes

Assuming RBCD is always malicious

RBCD can be legitimate. Some applications and service designs may use it intentionally. The goal is to determine whether it is required, documented, and limited.

Only reviewing traditional delegation settings

RBCD may not appear the same way as traditional constrained delegation. Reviewing only the Delegation tab can miss RBCD exposure.

Ignoring computer object ACLs

RBCD abuse often depends on write access to the target computer object. Object permissions are just as important as the delegation attribute itself.

Leaving MachineAccountQuota at the default without review

MachineAccountQuota can make some attack paths easier when combined with weak object permissions. It should be reviewed as part of AD hardening.

Clearing RBCD without understanding dependencies

Some services may rely on RBCD. Removing the configuration without testing can break application authentication.

Not monitoring attribute changes

RBCD risk can be introduced by a single attribute change. Monitor changes to msDS-AllowedToActOnBehalfOfOtherIdentity.

Forgetting Tier 0 systems

RBCD exposure on a normal workstation may be limited. RBCD exposure on a domain controller, certificate authority, management server, or identity system can be much more serious.

Practical recommendation

A practical RBCD review should include:

Identify all objects with msDS-AllowedToActOnBehalfOfOtherIdentity populated.
Determine whether each configuration is legitimate and documented.
Review which principals are allowed to delegate to each resource.
Review ACLs on sensitive computer objects.
Identify non-admin users or groups with write permissions over computer objects.
Review MachineAccountQuota.
Remove unnecessary RBCD configurations.
Reduce risky write permissions on computer objects.
Protect privileged accounts from delegation.
Monitor changes to RBCD-related attributes.
Investigate unexpected computer account creation.
Recheck regularly as part of Active Directory hygiene.

RBCD should be rare, intentional, documented, and monitored.

Summary

Resource-Based Constrained Delegation is a Kerberos delegation model where the target resource controls which accounts are allowed to delegate to it. It can support legitimate application scenarios, but it can also create serious security exposure when attackers can modify computer object permissions or delegation attributes.

The most important defensive focus areas are object permissions, populated RBCD attributes, MachineAccountQuota, privileged account protection, and monitoring for changes to delegation-related attributes. In a secure Active Directory environment, RBCD should be limited to documented use cases and reviewed regularly.