AdminSDHolder ACEs Propagate Silently Every 60 Minutes

The 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.