Active Directory Delegation: Unconstrained, Constrained, and RBCD Risks

1. Introduction

Kerberos delegation lets a service act on behalf of a user to a downstream service — the mechanism that makes multi-tier applications (a web front-end reaching a database as the actual user) work. It is legitimate and useful, but delegation configurations are among the most dangerous objects in Active Directory. An account trusted for the wrong kind of delegation can be turned into a path to impersonate any user, including domain administrators. Because delegation lives in easily-overlooked attributes on user and computer objects, it is a favourite target for privilege escalation and a frequent audit blind spot.

2. How It Works

There are three delegation models, in increasing order of safety:

• Unconstrained delegation: a service marked TrustedForDelegation receives a forwardable TGT for every user that authenticates to it, and caches it. The service can then impersonate that user to anything. This is the most dangerous model.
• Constrained delegation (KCD): the account may impersonate users only to a specific list of services (msDS-AllowedToDelegateTo). “Protocol transition” (TrustedToAuthForDelegation) additionally lets it request tickets for a user without the user first authenticating.
• Resource-Based Constrained Delegation (RBCD): the delegation trust is defined on the resource side via msDS-AllowedToActOnBehalfOfOtherIdentity — the target computer says “these accounts may act on behalf of users to me”. Powerful and increasingly abused because write access to a computer object can enable it.

User --auth--> Front-end service --impersonates user--> Back-end service

Unconstrained : front-end can impersonate the user to ANY service
Constrained   : front-end can impersonate ONLY to listed services
RBCD          : back-end lists WHICH accounts may impersonate to it

3. The Security Problem

Unconstrained delegation means any TGT that lands on that host — potentially a domain admin’s — can be reused to impersonate them everywhere. If an attacker controls (or coerces authentication to) an unconstrained-delegation host, they can capture privileged TGTs. Constrained delegation with protocol transition can be abused to obtain tickets for arbitrary users to the allowed services. RBCD is dangerous because an attacker who can write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a computer (via an ACL weakness or a controlled machine account) can grant themselves impersonation to that machine. Machine accounts and stale service accounts with delegation flags are common culprits.

4. How Attackers Abuse It

Concept: (a) Compromise or coerce authentication to an unconstrained host and harvest cached TGTs, including privileged ones. (b) Abuse protocol transition to request service tickets impersonating high-value users to the delegated service. (c) Configure RBCD on a target computer the attacker can write to, then impersonate a privileged user to it — a well-known escalation when combined with the ability to create or control a machine account.

In an authorized lab, each path is demonstrated against test objects to prove the misconfiguration exists; the report enumerates every delegation-enabled object and the fix, without touching real privileged identities.

5. How to Detect It

Command

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, OperatingSystem | Select-Object Name, OperatingSystem, TrustedForDelegation

What it does: Lists computers configured for unconstrained delegation.

What to look for: Any host here other than domain controllers (DCs are expected). Member servers with unconstrained delegation are high-risk and usually unnecessary.

Defensive use: Produces the priority remediation list — unconstrained delegation should be eliminated or converted to constrained/RBCD.

Command

Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName | Select-Object Name, Enabled, ServicePrincipalName

What it does: Finds user/service accounts flagged for unconstrained delegation.

What to look for: Enabled service accounts with this flag — a dangerous combination, especially if the account also has SPNs (roastable) and a weak password.

Defensive use: Highlights accounts that should be reconfigured and, ideally, added to Protected Users or marked sensitive.

Command

Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo, TrustedToAuthForDelegation | Select-Object Name, TrustedToAuthForDelegation, msDS-AllowedToDelegateTo

What it does: Lists accounts configured for constrained delegation and the services they may delegate to; also shows whether protocol transition is enabled.

What to look for: TrustedToAuthForDelegation = True (protocol transition) and delegation targets pointing at sensitive services (e.g. a DC service, LDAP, HOST).

Defensive use: Confirms the delegation scope is minimal and not pointed at tier-0 services.

Command

Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" } | Select-Object Name

What it does: Finds computers with an RBCD trust configured (the resource-side attribute is populated).

What to look for: Computers where RBCD is set unexpectedly — each represents an account that has been authorised to impersonate users to that machine. Verify every entry is intentional.

Defensive use: Detects RBCD backdoors/escalation setups and confirms only sanctioned relationships exist.

6. How to Audit the Environment

• Enumerate all unconstrained-delegation computers and users; expect only DCs (and ideally not even those beyond requirement).
• Review every constrained-delegation account and its target list; flag protocol transition.
• Enumerate all RBCD relationships and validate each is intentional.
• Confirm sensitive accounts are marked “Account is sensitive and cannot be delegated” and/or are in Protected Users.
• Check who can write the delegation-controlling attributes on computer objects (ACL review — see the ACLs article).

7. How to Fix / Harden It

• Eliminate unconstrained delegation; migrate to constrained delegation or RBCD scoped to the minimum services.
• Mark tier-0 and privileged accounts “Account is sensitive and cannot be delegated” and add them to Protected Users — their tickets then cannot be delegated at all.
• Restrict who can write msDS-AllowedToActOnBehalfOfOtherIdentity and computer-object attributes; limit machine-account creation (lower ms-DS-MachineAccountQuota to 0).
• Prefer gMSA for delegating services so credentials are strong and rotated.
• Keep delegation targets away from tier-0 services (LDAP, HOST on DCs).

8. Detection & Monitoring

• Event ID 5136 (directory object modified) on delegation attributes (msDS-AllowedToActOnBehalfOfOtherIdentity, msDS-AllowedToDelegateTo, userAccountControl delegation bits) — alert on any change.
• Event ID 4738 (user account changed) reflecting delegation-related UAC flag changes.
• Event ID 4769 service ticket requests that indicate impersonation to sensitive services from delegation hosts.
• Behavioural: a computer or service account suddenly requesting tickets for many users, or an RBCD attribute appearing on a computer outside a change window.

9. MITRE ATT&CK Mapping

Technique	ID
Steal or Forge Kerberos Tickets	T1558
Access Token Manipulation	T1134
Account Manipulation	T1098
Valid Accounts: Domain Accounts	T1078.002

10. Practical Lab

In an isolated lab:

1. Configure a member server for unconstrained delegation and confirm your TrustedForDelegation query flags it.
2. Set constrained delegation with protocol transition on a service account and verify the msDS-AllowedToDelegateTo query reveals the target and the protocol-transition flag.
3. Populate msDS-AllowedToActOnBehalfOfOtherIdentity on a test computer and confirm the RBCD query detects it; enable Event 5136 auditing and observe the modification event.
4. Mark a test admin as “sensitive and cannot be delegated”, add to Protected Users, and confirm delegation of its ticket is refused.
5. Set ms-DS-MachineAccountQuota to 0 and confirm standard users can no longer add machine accounts.

11. Key Takeaways

• Unconstrained delegation caches full TGTs — eliminate it outside tightly-controlled DCs.
• Protocol transition and RBCD are powerful; audit every instance and the ACLs that let them be set.
• Protect tier-0 accounts with “sensitive/cannot be delegated” and Protected Users.
• Set ms-DS-MachineAccountQuota to 0 to cut off a common RBCD escalation prerequisite.
• Alert on Event 5136 changes to delegation attributes — they should be rare and deliberate.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• Active Directory Certificate Services (AD CS): Auditing Templates Before They Become Domain Admin
• SMB Signing and NTLM Relay: Closing the Quiet Path to Lateral Movement
• LDAP and LDAP Signing in Active Directory: Channel Binding, Relay, and Hardening