Hardening Active Directory: Blue Team RBCD Defense Guide

Overview & Defensive Context#

In our morning research breakdown, we dissected the technical mechanics of Active Directory Resource-Based Constrained Delegation (RBCD) per technical specification [MS-SFU]. We demonstrated how an adversary who gains write permissions over a target computer object's Access Control List (DACL)—via rights such as GenericAll, GenericWrite, WriteOwner, WriteDacl, or explicit WriteProperty—can exploit default domain settings to achieve full local SYSTEM execution on the target.

By combining write access with the default ms-DS-MachineAccountQuota (which permits standard unprivileged users to register up to 10 computer accounts), an attacker provisions a rogue machine account (EVILPC$), writes its Security Identifier (SID) into the target's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, and executes the Kerberos Service-for-User (S4U2self and S4U2proxy) protocol transitions. This generates a cryptographically valid Kerberos Service Ticket impersonating a high-privilege domain administrator (such as a Domain Admin), granting unrestricted access to target services (CIFS, RPC, WMI, WinRM).

For identity architects and security operations centers (SOCs), defending against RBCD exposes critical operational vulnerabilities:

• Endpoint EDR Blindness: The configuration and ticket-generation phases of an RBCD attack occur entirely over LDAP (TCP 389/636) and Kerberos (TCP/UDP 88) directly against Domain Controllers. Endpoint Detection and Response (EDR) agents installed on target servers observe zero anomalous process creation, zero code injection, and zero memory manipulation until the attacker connects using a fully valid, KDC-signed Kerberos service ticket.
• Default Directory Auditing Gaps: In default Active Directory installations, modifications to directory object attributes—including msDS-AllowedToActOnBehalfOfOtherIdentity—are not audited. Security Event ID 4738 (User Account Modified) does not record computer attribute writes, and Event ID 4724 (Password Reset) does not fire. Without explicit System Access Control Lists (SACLs) capturing Event ID 5136, defenders remain completely blind to backdoor creation.
• The Pervasiveness of Delegated Permissions: In complex enterprise environments, computer object DACLs are frequently polluted by administrative delegation (e.g., Helpdesk tiers, server administration teams, Microsoft Exchange provisioning scripts, or SCCM service accounts). A single delegated group membership with GenericWrite over an organizational unit (OU) can expose hundreds of production servers to unilateral administrative takeover.

[!WARNING] Because RBCD is an intended, fully documented Kerberos protocol extension, Domain Controllers validate and process S4U requests by design. Defending against RBCD requires proactive architectural controls: neutralizing machine account creation, eliminating excessive DACL permissions, enforcing non-delegable security flags on privileged identities, and implementing real-time directory auditing.

This guide provides an enterprise-ready blue team defense blueprint: neutralizing ms-DS-MachineAccountQuota, configuring granular SACLs for Event ID 5136, enforcing Protected Users group policies, deploying production-grade Sigma detection rules, and executing a complete incident response triage playbook.

---

Architecture Hardening#

Securing Active Directory against Resource-Based Constrained Delegation requires establishing layered preventative boundaries: Eliminating Unprivileged Machine Account Creation, Enforcing Tiered DACL Least-Privilege Governance, and Locking Down Privileged Identities via Protected Users.

Defense Architecture Flowchart#

flowchart TD
    classDef attacker fill:#1e293b,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    classDef boundary fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef iam fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef audit fill:#4c1d95,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef drop fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef success fill:#065f46,stroke:#34d399,stroke-width:2px,color:#a7f3d0

    Attacker[Adversary with Delegated Write Access]:::attacker --> MAQCheck{Ring 1: MachineAccountQuota Gate}:::boundary
    
    MAQCheck -- ms-DS-MachineAccountQuota = 0 --> Drop1[Action: Deny Computer Account Creation]:::drop
    MAQCheck -- Pre-Existing Account Controlled --> DACLCheck{Ring 2: Target Computer DACL Boundary}:::boundary
    
    DACLCheck -- Missing GenericWrite or WriteProperty Rights --> Drop2[Action: LDAP Write Denied INSUFFICIENT_ACCESS]:::drop
    DACLCheck -- Unauthorized Write Attempted on Audited Target --> SACLEvent[Ring 3: SACL Engine Logs Event ID 5136]:::audit
    
    SACLEvent --> KDCCheck{Ring 4: KDC Delegation & Identity Policy}:::iam
    KDCCheck -- Target User in Protected Users Security Group --> Drop3[Action: KDC Refuses S4U Ticket KDC_ERR_BADOPTION]:::drop
    KDCCheck -- Account Flagged: Sensitive and Cannot be Delegated --> Drop3
    
    KDCCheck -- Unprotected Account & Unhardened DACL --> Compromise[Vulnerability Exploited: Service Ticket Issued]:::drop
    KDCCheck -- Hardened Configuration & Audited Boundary --> SecureState[RBCD Vector Neutralized & SOC Alerted]:::success

Layer 1: Restricting Machine Account Creation (MachineAccountQuota = 0)#

By default, Active Directory permits any authenticated domain user to join up to 10 computer accounts to the domain via the ms-DS-MachineAccountQuota attribute. Attackers leverage this capability to autonomously provision the attacker-controlled machine account required to execute S4U protocol transitions.

Eliminate unprivileged computer creation by setting ms-DS-MachineAccountQuota to 0:

POWERSHELL

# PowerShell: Restricting MachineAccountQuota to 0 across the domain
Import-Module ActiveDirectory

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

## Verify the updated attribute
Get-ADDomain | Select-Object DistinguishedName, @{Name="MachineAccountQuota"; Expression={$_.CustomProperties["ms-DS-MachineAccountQuota"]}}

Once set to 0, standard domain users cannot execute addcomputer.py or New-MachineAccount. Domain-join operations must be explicitly delegated to designated service accounts scoped to specific Organizational Units (OUs), or executed using offline domain join (djoin.exe).

Layer 2: Tiered DACL Hardening & Stripping Delegated Write Rights#

RBCD attacks require write access over the target computer object. Blue teams must audit and remove dangerous access control entries (ACEs) on Tier-0 and Tier-1 computer accounts:

1. Audit High-Risk Permissions: Identify non-administrative principals holding GenericAll, GenericWrite, WriteOwner, WriteDacl, or explicit write rights on msDS-AllowedToActOnBehalfOfOtherIdentity (Schema GUID: 3f78c394-2570-4e32-8066-569d1f69277b):

POWERSHELL

# Audit computer objects for high-risk write permissions
Get-ADComputer -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $Computer = $_
    $Acl = Get-Acl "AD:\$($Computer.DistinguishedName)"
    $Acl.Access | Where-Object {
        $_.ActiveDirectoryRights -match "GenericAll|GenericWrite|WriteDacl|WriteOwner" -and
        $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM"
    } | Select-Object @{Name="Computer"; Expression={$Computer.Name}}, IdentityReference, ActiveDirectoryRights
}

2. Remediate Excessive Rights: Remove unprivileged accounts, helpdesk groups, and service principals from computer object ACLs. Enforce strict administrative tiering: Tier-0 computer objects (Domain Controllers, PKI nodes) must only be modifiable by Tier-0 administrators.

Layer 3: Enforcing Protected Users & Non-Delegable Account Flags#

The ultimate objective of an RBCD attack is to impersonate a high-privilege account. If the target account cannot be delegated, the KDC will refuse to issue a service ticket via S4U2proxy:

1. Enroll Tier-0 Administrators into the Protected Users Group: Active Directory provides the built-in Protected Users security group (introduced in Windows Server 2012 R2). For all members of this group:
   • The KDC will never delegate credentials using constrained or unconstrained delegation.
   • Kerberos S4U2self and S4U2proxy requests requesting service tickets for Protected Users are rejected with KDC_ERR_BADOPTION.
   • NTLM authentication, DES, and RC4 encryption are disabled.

POWERSHELL

# Adding Domain Administrators to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "Domain Admins", "Enterprise Admins"

2. Enable Non-Delegable Flag on Service and Sensitive Accounts: For accounts that cannot be added to Protected Users due to compatibility constraints, configure the USER_NOT_DELEGATED flag (Control code: 0x100000):

POWERSHELL

# Flag sensitive accounts as non-delegable
Get-ADUser -Filter {AdminCount -eq 1} | Set-ADAccountControl -CannotBeDelegated $true

---

Production Detection Queries#

Blue teams must deploy detection covering directory modification telemetry (Event ID 5136) and Kerberos ticket issuance telemetry (Event ID 4769).

Production Sigma Rule: Active Directory RBCD Attribute Modification (Event 5136)#

The following Sigma rule detects unauthorized writes to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute in Active Directory event logs:

YAML

title: Active Directory Resource-Based Constrained Delegation Modification
id: c71a4f89-8123-42e1-912b-3194a8bc1209
status: production
description: |
  Detects modifications to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on Active Directory
  computer objects (Event ID 5136). Threat actors populate this attribute to configure Resource-Based
  Constrained Delegation (RBCD) for lateral movement and privilege escalation.
references:
  - https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/
  - https://attack.mitre.org/techniques/T1558/

tags:
  - attack.privilege_escalation
  - attack.persistence
  - attack.t1558
  - attack.lateral_movement
  - attack.t1550.003
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-AllowedToActOnBehalfOfOtherIdentity'
    OperationType: '%%14674' # Value Added
  filter_known_admin:
    SubjectUserName|endswith: '$' # Filter legitimate machine trust synchronization if applicable
  condition: selection and not filter_known_admin
fields:
  - SubjectUserName
  - SubjectDomainName
  - ObjectDN
  - AttributeValue
  - ObjectClass
falsepositives:
  - Legitimate administrative tooling explicitly configuring server farm delegation.
level: critical

Enforcing System Access Control Lists (SACL) for Event 5136#

Active Directory does not generate Event ID 5136 by default. Blue teams must configure a SACL on computer objects to audit attribute modifications:

POWERSHELL

# PowerShell: Configuring SACL to audit writes on msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module ActiveDirectory

$DomainDN = (Get-ADDomain).DistinguishedName
$TargetOU = [ADSI]"LDAP://OU=Servers,$DomainDN"

## Attribute schema GUID for msDS-AllowedToActOnBehalfOfOtherIdentity
$AttrGuid = [GUID]"3f78c394-2570-4e32-8066-569d1f69277b"
$EveryoneSid = New-Object System.Security.Principal.SecurityIdentifier("S-1-1-0")

## Define SACL entry: Audit Success on WriteProperty
$AuditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    $EveryoneSid,
    "WriteProperty",
    "Success",
    $AttrGuid,
    "Descendents",
    [GUID]"bf967a86-0de6-11d0-a285-00aa003049e2" # Computer class GUID
)

$Acl = $TargetOU.ObjectSecurity
$Acl.AddAuditRule($AuditRule)
$TargetOU.CommitChanges()

Windows Event ID 4769: Detecting Anomalous S4U Kerberos Ticket Requests#

When S4U2proxy is executed, the KDC logs Security Event ID 4769 (A Kerberos service ticket was requested). Threat hunting teams can filter for S4U delegation options:

KQL

# Microsoft Sentinel KQL: Detect S4U2proxy Kerberos Ticket Requests
SecurityEvent
| where EventID == 4769
| where TicketOptions has "0x40810000" or TicketOptions has "0x40800000" // Forwardable & S4U delegation flags
| where TargetUserName endswith "$" // Requesting service is a computer account
| where ServiceName !startswith "krbtgt"
| where TargetUserName != ServiceName
| project TimeGenerated, TargetUserName, ServiceName, ServiceSid, TicketOptions, IpAddress
| order by TimeGenerated desc

---

Enterprise Mitigation Matrix#

When prioritizing defensive mitigations against RBCD abuse, security architects must evaluate operational impact against blast radius reduction:

Remediation Strategy	Implementation Effort	Blast Radius & Operational Risk	Detection & Prevention Efficacy	Performance Overhead	Architectural Longevity
Workaround: Set MachineAccountQuota = 0	15 Minutes (Immediate domain-level attribute update via PowerShell)	Low Standard users cannot self-join machines; automated join pipelines must use designated service accounts.	High (90%) Denies unprivileged attackers the rogue machine accounts needed for S4U protocol transitions.	Zero (Standard Active Directory configuration).	Permanent Best Practice Eliminates an entire class of machine-based AD attacks.
Hotfix: Protected Users & CannotBeDelegated Flags	1 - 2 Hours (Add Tier-0 admins to Protected Users group)	Low to Moderate Disables NTLM and RC4 for members; requires testing legacy authentication dependencies.	Comprehensive for Privileged Users KDC strictly rejects S4U2proxy impersonation of protected identities.	Zero KDC enforcement at ticket issuance.	Mandatory Milestone Hardens administrative identity tiering against delegation theft.
Architecture Fix: Tiered DACL Cleanup & SACL Auditing	2 - 4 Weeks (Audit computer object ACLs, remediate delegation, deploy SACLs)	Moderate Requires discovering existing operational delegations and replacing broad rights with scoped RBAC.	Absolute (100%) Removes the ability to write to msDS-AllowedToActOnBehalfOfOtherIdentity entirely.	Negligible (Directory audit logging overhead < 0.5%).	Permanent State Zero-trust Active Directory object governance.

[!IMPORTANT] Setting MachineAccountQuota = 0 is an essential emergency control, but it does not prevent an attacker who has already compromised an existing machine account or service principal from configuring RBCD. Thorough DACL remediation and Protected Users enforcement are mandatory for comprehensive protection.

---

Incident Response & Verification Playbook#

If an adversary is suspected of establishing persistence or moving laterally via Resource-Based Constrained Delegation, execute the following four-phase incident response playbook:

flowchart TD
    classDef check fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#fef3c7
    classDef alert fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef clean fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef triage fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd

    Start[Step 1: Scan Domain for Populated RBCD Attributes]:::triage --> AuditRBCD{msDS-AllowedToActOnBehalfOfOtherIdentity Populated?}:::check
    AuditRBCD -- Yes --> DecodeSD[Step 2: Decode Security Descriptors & Extract SIDs]:::triage
    AuditRBCD -- No --> CleanDomain[No Static RBCD Backdoors Detected]:::clean
    
    DecodeSD --> CheckTrust{Are Delegated Machine Accounts Authorized?}:::check
    CheckTrust -- Unauthorized / Rogue Machine Account --> DeclareIncident[Declare Severity 1 Incident: Active Persistence]:::alert
    CheckTrust -- Approved Multi-Tier Architecture --> DocumentBaseline[Update Authorized Baseline]:::clean
    
    DeclareIncident --> PurgeAttribute[Step 3: Clear Attribute & Delete Rogue Accounts]:::alert
    PurgeAttribute --> RevokeSessions[Step 4: Purge KDC Ticket Caches & Reset Passwords]:::alert
    RevokeSessions --> VerifyHardening[Verify MAQ = 0 and Apply SACL Auditing]:::clean

Phase 1: Live Directory Audit & RBCD Inventory#

Execute an immediate inventory scan across all Active Directory computer objects to identify any accounts configured with resource-based delegation:

POWERSHELL

# PowerShell: Discover all computer objects with RBCD configured
Import-Module ActiveDirectory

$RBCDComputers = Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity | 
    Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" -ne $null }

$RBCDComputers | ForEach-Object {
    $Comp = $_
    $RawSD = $Comp."msDS-AllowedToActOnBehalfOfOtherIdentity"
    $SecurityDescriptor = New-Object System.Security.AccessControl.RawSecurityDescriptor($RawSD, 0)
    
    foreach ($Ace in $SecurityDescriptor.DiscretionaryAcl) {
        $Account = (New-Object System.Security.Principal.SecurityIdentifier($Ace.SecurityIdentifier.BinaryLength, 0)).Translate([System.Security.Principal.NTAccount]) rescue $Ace.SecurityIdentifier.Value
        [PSCustomObject]@{
            TargetComputer   = $Comp.Name
            AuthorizedCaller = $Account
            CallerSID        = $Ace.SecurityIdentifier.Value
            AccessMask       = $Ace.AccessMask
        }
    }
} | Format-Table -AutoSize

Phase 2: Correlating Rogue Accounts & Ticket Telemetry#

1. Audit Newly Created Computer Accounts (Event ID 4741): Search Domain Controller security logs for computer accounts provisioned within the investigation window:

POWERSHELL

# Query Event ID 4741: A computer account was created
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4741; StartTime=(Get-Date).AddDays(-7)} | ForEach-Object {
    $Event = [xml]$_.ToXml()
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        CreatedBy   = $Event.Event.EventData.Data | Where-Object {$_.Name -eq 'SubjectUserName'} | Select-Object -ExpandProperty '#text'
        ComputerName= $Event.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'} | Select-Object -ExpandProperty '#text'
    }
}

2. Inspect Target Host Logons (Event ID 4624): Query target computers for Network Logons (Logon Type 3) occurring shortly after delegation configuration, specifically checking for impersonated administrative accounts.

Phase 3: Eradication & Attribute Remediation#

1. Sanitize msDS-AllowedToActOnBehalfOfOtherIdentity: Clear the binary security descriptor on all compromised computer objects:

POWERSHELL

# Remove RBCD configuration from compromised host
Set-ADComputer -Identity "WORKSTATION01" -Clear "msDS-AllowedToActOnBehalfOfOtherIdentity"

2. Disable and Delete Rogue Machine Accounts:

POWERSHELL

# Disable and remove rogue machine account
Disable-ADAccount -Identity "EVILPC$"
Remove-ADComputer -Identity "EVILPC$" -Confirm:$false

3. Purge Ticket Caches and Invalidate Forged Sessions: Force ticket cache invalidation across the impacted targets and Domain Controllers:

POWERSHELL

# Purge Kerberos ticket cache on target systems
klist -lh 0 -li 0x3e7 purge

If Domain Admin accounts were impersonated, execute a controlled password rotation of the krbtgt account (two rotations spaced 24 hours apart) to invalidate all existing Ticket Granting Tickets across the forest.

Phase 4: Post-Remediation Verification Checklist#

Before declaring the incident resolved:

• Verify ms-DS-MachineAccountQuota is confirmed set to 0.
• Confirm that msDS-AllowedToActOnBehalfOfOtherIdentity is $null on all non-exempt computers.
• Ensure all Tier-0 administrators are active members of the Protected Users security group.
• Verify SACL auditing is active and producing Event ID 5136 upon test attribute modification.

---

Authoritative References#

1. Microsoft Technical Specification: [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol — Microsoft Learn
2. Microsoft Learn: Resource-Based Constrained Delegation Overview and Configuration — Microsoft Documentation
3. CISA & NSA Cybersecurity Advisory: Active Directory Security: Mitigating Kerberos Delegation Abuse — CISA Cybersecurity Best Practices
4. National Institute of Standards and Technology (NIST): SP 800-207: Zero Trust Architecture & Enterprise Identity — NIST Special Publications