AdminSDHolder Stale ACLs: Rights That Outlive Admin Status
AdminSDHolder Stale ACLs: Rights That Outlive Admin Status sits in the Active Directory Privileged Access risk register because a small configuration shortcut can widen access, weaken control boundaries, or hide failure conditions. The risk usually starts with every 60 minutes, the SDProp process on the PDC emulator scans CN=AdminSDHolder,CN=System,DC=domain and copies its security descriptor onto every member of protected groups: Domain In production, the concern is a user who spent three weeks in Domain Admins during
The Trap
AdminSDHolder ACL inheritance disabled on former privileged accounts, with adminCount left permanently set to 1.
The Default State
Every 60 minutes, the SDProp process on the PDC emulator scans CN=AdminSDHolder,CN=System,DC=domain and copies its security descriptor onto every member of protected groups: Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, and a handful of others hardcoded into the AdminSDHolder exclusion list controlled by the 16th character of dsHeuristics. Alongside the ACL copy, SDProp sets adminCount=1 and flips the SE_DACL_PROTECTED bit, stripping inherited permissions from the object so a compromised OU delegation can’t touch a privileged account. This is correct and deliberate behaviour. What Microsoft does not do, by design, is reverse it. When an account is removed from every protected group, adminCount stays at 1 and inheritance stays disabled indefinitely. Nobody flags this because the account still authenticates fine.
The Blast Radius
A user who spent three weeks in Domain Admins during an incident five years ago still carries that frozen ACL today, even though they’re now a standard user in a completely different OU. Any subsequent hardening applied at the OU level — tighter delegated reset-password rights, new Tier 0 restriction GPOs, updated auditing ACEs — silently fails to apply to that account because inheritance is switched off. Security teams running OU-based delegation audits see clean results while these accounts sit outside every policy boundary. Attackers who understand this pivot toward stale adminCount=1 accounts specifically, since their ACLs often retain permissive entries that current policy would never grant a standard user.
The Lead Mechanic Fix
Run a scheduled reconciliation: Get-ADObject -LDAPFilter '(adminCount=1)' -Properties adminCount,memberOf, cross-reference membership against the current protected groups list, and for every account with no active membership, reset adminCount to $null and re-enable inheritance with dsacls "DN" /P:N followed by dsacls "DN" /I:S to restore inherited ACEs from the parent OU. Do not run this manually and once — schedule it weekly via a signed script under change control, since SDProp will re-protect any account re-added to a privileged group on its next 60-minute pass regardless.