ADACL-008: OU Delegation Analysis
- Platform
- Active Directory
- Category
- AD ACL & Delegation
- Severity
- Medium
- Zero Trust pillar
- Identity (weight 1)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check walks every Organizational Unit and container under the domain naming context and reads the nTSecurityDescriptor attribute via LDAP. For each Access Control Entry it evaluates: the trustee SID and whether it resolves to a live, enabled principal; the ActiveDirectoryRights mask (GenericAll, GenericWrite, WriteDACL, WriteOwner, WriteProperty, CreateChild, DeleteChild, ExtendedRight); the ObjectType GUID (which schema attribute or extended right is granted); the InheritedObjectType GUID (which child object class the ACE applies to); and the InheritanceType (None, Descendents, SelfAndChildren, All). ACEs are compared against the schema default security descriptor for the OU object class so that built-in inheritance from the domain root is not flagged. Findings are produced when: a non-builtin trustee holds GenericAll, GenericWrite, WriteDACL, or WriteOwner on the OU; CreateChild or DeleteChild is granted without an InheritedObjectType scoping it to a single class; WriteProperty is granted over sensitive attributes (userAccountControl, servicePrincipalName, msDS-AllowedToActOnBehalfOfOtherIdentity, msDS-KeyCredentialLink, member); the trustee SID is orphaned (S-1-5-21-... with no matching object) or resolves to a disabled or stale account; or an ACE is inherited from a parent OU into a child OU containing higher-tier objects.
Why it matters
OU delegation determines who can read, modify, create, and delete the user, computer, group, and gMSA objects beneath it. A single excessive ACE on an OU containing Tier 0 or Tier 1 assets converts a helpdesk-level breach into a domain compromise. Concrete blast radius for a low-privilege attacker who controls a principal with abusive rights on an OU: GenericAll or WriteDACL on the OU grants the right to write a new ACE on any child object, including resetting passwords of users in the OU, taking ownership of computer objects, or writing msDS-KeyCredentialLink to perform Shadow Credentials (UnPAC-the-Hash). WriteProperty on servicePrincipalName on child users enables targeted Kerberoasting of accounts the attacker selects. WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity on a child computer enables Resource-Based Constrained Delegation (RBCD) takeover of that host. CreateChild for user objects lets an attacker plant a new account inside a sensitive OU that may inherit GPO-applied privilege, bypassing joiner workflow controls. Beyond the technical reach, undocumented delegations are an audit and recertification failure: SOX, PCI DSS, ISO 27001 A.9.2.5, and NIST SP 800-53 AC-6(7) all require periodic review of access, and stale OU ACEs are routinely missed because Active Directory Users and Computers (ADUC) does not surface them in the default view.
Attack path
1. Initial recon: from any domain-joined host with a low-privilege account, run BloodHound / SharpHound with the ACL collection method, or use PowerView Get-DomainObjectAcl -ResolveGUIDs against each OU. The collector reads nTSecurityDescriptor over LDAP and maps every ACE to a graph edge. 2. Path selection: in BloodHound, the attacker queries for outbound rights from owned principals to OU nodes (GenericAll, WriteDACL, WriteOwner, AddSelf, AllExtendedRights), then expands to child users and computers via the OwnsOU / GenericAll edges. The shortest path query frequently terminates at a Tier 0 group or a privileged user object. 3. Abuse, user objects: with WriteDACL on the OU, write a new ACE granting GenericAll to the controlled principal on a chosen child user, then reset the password (Set-DomainUserPassword) or write a Shadow Credential to msDS-KeyCredentialLink using Whisker or Certipy shadow-credentials. 4. Abuse, computer objects: with GenericAll on a computer object via OU inheritance, write msDS-AllowedToActOnBehalfOfOtherIdentity to point at an attacker-controlled computer account (RBCD), then request a service ticket as any user via S4U2Self + S4U2Proxy with Rubeus. 5. Abuse, group objects: with WriteProperty on the member attribute via the OU ACE, add the controlled user to a privileged group housed in the OU. 6. Persistence: write a deny-inherit ACE or rewrite the OU security descriptor to hide the abused ACE from default ADUC views, while retaining the access path.
How Guerrilla assesses it
Guerrilla reads the OU tree via System.DirectoryServices.Protocols, binds the nTSecurityDescriptor of each OU, and parses it with System.DirectoryServices.ActiveDirectorySecurity. Each non-inherited ACE is evaluated against an allowlist of built-in trustees (Domain Admins, Enterprise Admins, SYSTEM, Account Operators, Pre-Windows 2000 Compatible Access where applicable). For non-allowlisted trustees the check resolves the SID to a current AD object via the SID resolver cache; orphaned SIDs (no matching object) are reported as stale delegations. ObjectType and InheritedObjectType GUIDs are resolved against the schema via the well-known rights GUID table (msDS-KeyCredentialLink = 5b47d60f-6090-40b2-9f37-2a4de88f3063, User-Force-Change-Password = 00299570-246d-11d0-a768-00aa006e0529, etc.). Inheritance flags are walked top-down so that ACEs applied at the domain root and inherited into every OU are reported once with their scope, not per-OU. Output includes OU distinguishedName, trustee SamAccountName or stale-SID marker, ActiveDirectoryRights, ObjectType resolved name, InheritanceType, and a risk classification (Critical / High / Medium) based on the rights mask and whether the trustee is privileged.
Recommended value
All OU delegations documented, scoped to specific object types, and using least-privilege permissions
Remediation
Review all non-default ACEs on each OU using dsacls.exe or PowerShell. Verify that delegations use the InheritedObjectType to scope permissions to specific object classes. Remove delegations that are no longer required. Document all intentional delegations in an authorization matrix.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6, AC-6(3), CM-5
- MITRE ATT&CK
- T1222.001