AdminSDHolder ACEs Propagate Silently Every 60 Minutes
An ACE added directly to the AdminSDHolder object in CN=System replicates onto every protected AD principal via SDProp, but because inheritance is disabled downstream, OU-based ACL reviews never see it, and the grant outlives any later group membership change on Windows Server Active Directory.
At a glance
- Unsafe setting
- An explicit ACE added directly to the AdminSDHolder object in CN=System rather than through tier-0 delegation controls.
- Failure trigger
- The hourly SDProp cycle copies the ACE onto every adminCount=1 protected object, and SE_DACL_PROTECTED then blocks its removal via normal OU cleanup.
- Blast radius
- A helpdesk or service account can retain permanent, inheritance-immune rights over every tier-0 account in the forest, invisible to OU-scoped ACL audits.
- Recommended control
- Baseline and diff the AdminSDHolder SDDL on a fixed schedule and strip non-default ACEs from every protected object individually, not just from AdminSDHolder.
Fix commands and configuration
dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /AThe Trap
SDProp (Security Descriptor Propagator) copies the ACL from AdminSDHolder onto every account flagged adminCount=1 — Domain Admins, Enterprise Admins, Schema Admins, and the built-in service accounts protected by AD’s tiering model. To make that inherited ACL stick, SDProp sets the SE_DACL_PROTECTED bit on the target object, which strips ACE inheritance from the parent OU entirely. Administrators reviewing privilege end up checking OU-linked delegation and GPO-based ACLs, since that’s where every other object in the domain gets its permissions. AdminSDHolder itself, sitting quietly in CN=System, rarely gets audited directly.
The Default State
SDProp runs automatically every 60 minutes (controlled by the AdminSDProtectFrequency registry value on the PDC emulator, default 3600 seconds) and requires no configuration to function. This is intentional Microsoft behaviour, not a vendor misconfiguration — the trap is that a helpdesk or automation ticket asking for “faster password reset access on privileged accounts” often gets resolved by adding an ACE straight onto CN=AdminSDHolder,CN=System,DC=domain,DC=com rather than through a proper tier-0 access model. That single ACE, added once, now qualifies as the template.
The Blast Radius
The next SDProp cycle pushes that ACE onto every protected account in the forest, including Domain Admins members added afterwards. Because inheritance is disabled on those objects (SE_DACL_PROTECTED), removing the source ACE from AdminSDHolder later does not retract it from accounts that already received the copy — each protected object now holds its own explicit ACE, immune to OU permission cleanup, GPO changes, or delegation wizard resets. A helpdesk group granted GenericAll during a single change request becomes a permanent, invisible path to Domain Admin, and standard ACL audits scoped to OU inheritance chains report nothing wrong because the grant was never inherited from an OU in the first place.
The Lead Mechanic Fix
Run dsacls "CN=AdminSDHolder,CN=System,DC=domain,DC=com" /A and diff the output against a known-good baseline SDDL string on a fixed schedule, not ad hoc. Remove any ACE that is not part of the default Microsoft-defined set (SYSTEM, Domain Admins, Enterprise Admins, Administrators). For accounts already infected via propagation, you must explicitly strip the ACE from each affected object — clearing AdminSDHolder alone will not roll it back. Use BloodHound or PingCastle’s AdminSDHolder-specific check to enumerate every protected object’s explicit ACEs, and gate any future change to AdminSDHolder itself behind a tier-0 change control process, never a standard helpdesk ticket.