AdminSDHolder's Automatic ACL Reset Silently Restores Revoked Access to Domain Admins

Symptom

An administrator removes a suspicious access control entry (ACE) from the Domain Admins group, confirms the group’s access control list looks clean, and later finds the identical entry restored on that group, or on another protected group such as Enterprise Admins, without anyone touching the object again.

This typically surfaces during an incident review: a low-privilege service account or unfamiliar security principal is found holding rights such as GenericAll or WriteDACL on a highly privileged group. The entry is removed, the change is verified with a fresh Get-Acl query, and the case appears closed. Hours later, the same entry, or an equivalent one, is present again, and no audit log shows a human or script editing the group directly.

False Assumption

The natural but incorrect assumption is that an ACE removed from a protected group or account is durable, because nothing visible, no scheduled task, Group Policy Object or script, appears to be reapplying it. Administrators reasonably conclude that once the object’s own security descriptor is clean, the exposure is closed.

This assumption ignores a background Active Directory mechanism that does not act on the protected object at all. It acts on a separate template object and copies that template’s permissions onto every protected object on a recurring schedule, independent of any change made directly to the protected object itself.

Root Cause

The template object is CN=AdminSDHolder,CN=System, and the mechanism is Active Directory’s Security Descriptor Propagator, commonly abbreviated SDProp. On a periodic cycle, SDProp copies AdminSDHolder’s access control list onto every account and group that Active Directory considers protected, including Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators and several other built-in privileged groups and their members. Protected objects are marked with an adminCount attribute set to 1.

If the unauthorised ACE was added directly to AdminSDHolder rather than only to the downstream group, removing it from the downstream group changes nothing meaningful: the next SDProp cycle simply copies AdminSDHolder’s ACL, including the unauthorised entry, back onto the group. Historical Microsoft documentation has described a default propagation interval measured in tens of minutes, but the exact current default, and whether it has been overridden for a given domain via the dSHeuristics attribute, is version- and configuration-dependent and should be confirmed against current Microsoft documentation for the deployed functional level before being relied upon operationally.

Impact

Because SDProp reapplies AdminSDHolder’s ACL on a recurring cycle, an attacker or a careless automation script that successfully edits AdminSDHolder gains a self-healing, domain-wide foothold across every current and future protected group and account, while defenders who only clean the downstream object observe the access silently return.

The practical consequence is a false sense of resolution. An incident that looks closed after removing an ACE from Domain Admins may in fact still be open, with the same or an equivalent entry propagating back to every protected object in the domain on each cycle. This is especially damaging during active incident response, where a team may stand down before the true source has been addressed.

Diagnosis

Diagnosis has two parts: confirming that AdminSDHolder itself carries the unauthorised entry, and establishing the full scope of protected objects that have received it.

1. Enumerate the current ACL on AdminSDHolder directly, rather than on the protected group where the entry was first observed.
2. Compare the enumerated ACL against a known-good baseline for the domain, if one exists, or against the documented set of default AdminSDHolder entries for the deployed AD functional level.
3. List every object currently flagged adminCount=1 to understand the full blast radius of anything found on AdminSDHolder.
4. Correlate the timestamp of the ACE’s reappearance on the downstream group with the domain’s SDProp cycle, to confirm propagation rather than a separate, direct re-grant.

Get-Acl "AD:CN=AdminSDHolder,CN=System,DC=example,DC=com" | Format-List *

Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,distinguishedName | Select-Object Name,distinguishedName

Correction

The durable fix is to remove the unauthorised access control entry from the AdminSDHolder object itself, not merely from the downstream protected group or account where it was first observed.

1. Export and retain the current AdminSDHolder security descriptor before making any change, so the exact prior state can be restored if needed.
2. Identify the precise access rule to remove, confirming the identity reference, rights and access control type match the unauthorised entry rather than a legitimate delegation.
3. Remove that rule from AdminSDHolder using an ACL edit that operates on the object directly.
4. Do not attempt to fix downstream protected objects individually; correcting AdminSDHolder and allowing the next SDProp cycle to repropagate is the supported path, since manually editing every protected object is error-prone and will be overwritten regardless.

$acl = Get-Acl "AD:CN=AdminSDHolder,CN=System,DC=example,DC=com"
$acl.RemoveAccessRule($ruleToRemove)
Set-Acl "AD:CN=AdminSDHolder,CN=System,DC=example,DC=com" $acl

Validation

Confirm the fix by re-inspecting AdminSDHolder’s ACL immediately after the change and again after a full SDProp cycle has elapsed, checking that the entry has not been reintroduced anywhere in the domain.

• Re-run the AdminSDHolder ACL query immediately after the change and confirm the unauthorised identity reference is absent.
• Wait for a confirmed full propagation cycle for the domain (verify the current interval and any dSHeuristics override with the AD team rather than assuming a fixed duration) before re-checking downstream objects.
• Re-query protected group members and confirm their ACLs now match the cleaned AdminSDHolder ACL, with no residual unauthorised entry.
• Re-run the adminCount=1 query to confirm the protected-object population has not changed unexpectedly during remediation.

Rollback

If removing the entry from AdminSDHolder breaks a permission that was, in fact, an intentional delegation implemented at the AdminSDHolder level, restore the exported baseline security descriptor and reassess the delegation design before making further changes.

• Restore the pre-change AdminSDHolder security descriptor from the export captured before remediation.
• Confirm with a fresh ACL query that the restored state exactly matches the backup.
• Document why the original entry existed and route any genuine delegation requirement through change control and a scoped, OU-based delegation model rather than a direct AdminSDHolder edit.
• Do not attempt to restore individual downstream protected-object ACLs by hand; let SDProp repropagate the restored AdminSDHolder ACL on its normal cycle.

Prevention

Prevent recurrence by treating AdminSDHolder as a high-value, actively monitored object rather than an obscure internal mechanism.

• Maintain a version-controlled baseline export of AdminSDHolder’s ACL and diff against it periodically.
• Enable directory service auditing on AdminSDHolder so any modification generates an alert independent of routine change windows.
• Periodically review the full adminCount=1 population for stale protection flags on accounts that no longer need privileged status.
• Require any legitimate customisation of privileged-group access to be implemented through a documented, reviewed delegation model, never as an ad hoc direct edit to AdminSDHolder.
• Treat any unexplained AdminSDHolder ACE as a security incident requiring escalation, not a routine ACL clean-up task.