SDProp Silently Reverts Direct Group ACL Edits

The Trap

Direct ACE modification on protected group objects – Domain Admins, Enterprise Admins, Schema Admins, Backup Operators – instead of on the AdminSDHolder template object they inherit from. An engineer opens the Security tab in ADUC (or runs a scripted Set-Acl against the group’s distinguishedName), adds an ACE granting a Tier-1 helpdesk group Reset Password or Write Member rights, and confirms the change applied. It looks permanent because nothing challenges it immediately.

The Default State

SDProp runs on the PDC emulator on a fixed interval controlled by AdminSDProtectFrequency under HKLMSYSTEMCurrentControlSetServicesNTDSParameters, defaulting to 3600 seconds. Any object flagged adminCount=1 has its discretionary ACL replaced wholesale – not merged – with a verbatim copy of the ACL on CN=AdminSDHolder,CN=System,DC=<domain>. The vendor ships AdminSDHolder’s own ACL untouched from install, so any legitimate delegation must be written there, but every administrative tool makes it just as easy to write to the protected object directly, which is where most engineers instinctively look.

The Blast Radius

Because SDProp overwrites rather than merges, the custom ACE disappears with no deletion event tied to the person who added it. Directory Service Changes auditing (event 5136) attributes the change to the SDProp process context, not the operator, so incident response chases the wrong actor while the real cause – a scheduled propagation cycle – goes unreviewed. The operational failure surfaces at the worst time: a Tier-1 group’s delegated right to reset a locked-out Domain Admin account vanishes silently sometime in the preceding hour, breaking the break-glass procedure during an actual outage. The inverse failure is worse: if someone edits AdminSDHolder directly by mistake – adding a broad Authenticated Users ACE meant for one group – that ACE propagates unchanged to every adminCount=1 object domain-wide on the next cycle, instantly granting the error to Domain Admins, Enterprise Admins, Schema Admins and every historically protected account at once.

The Lead Mechanic Fix

Treat CN=AdminSDHolder,CN=System,DC=corp,DC=local as the only legitimate write target for protected-group delegation. Add rights there directly: dsacls “CN=AdminSDHolder,CN=System,DC=corp,DC=local” /G “CORPTier0-Helpdesk:CA;Reset Password;user” – never touch the group object’s own Security tab. After any AdminSDHolder change, force immediate propagation rather than waiting for the default 3600-second cycle: bind to RootDSE with ldp.exe and issue a Modify operation setting attribute fixupInheritance to 1 (Replace), which triggers SDProp synchronously so the change is validated in the same maintenance window it was made. Gate every AdminSDHolder write behind change control, and run a scheduled dsacls export compared against the last approved baseline, alerting on any delta submitted outside a ticket – this catches accidental edits to protected group objects and unauthorised AdminSDHolder tampering before the next SDProp cycle turns either one into a domain-wide grant.