Skip to main content
cd ../config-traps
risk/register/adminsdholder-stale-acls-rights-that-outlive-admin-status.html
Active Directory Privileged Accesshigh severityActive Directory

AdminSDHolder Stale ACLs: Rights That Outlive Admin Status

Severity
high
Reviewed
12 Jul 2026
Remediation
~20 minutes
Overview

Removing an account from Domain Admins leaves adminCount stuck at 1 and inheritance disabled, so the stale AdminSDHolder ACL persists forever. New OU-level hardening, tighter delegation, restriction GPOs, silently fails to apply, leaving a formerly privileged account holding permissive rights invisible to routine delegation audits.

Operational summary

At a glance

Symptom
SDProp protects account once, group membership removed later, ACL and inheritance flag never revert
Likely cause
adminCount=1 and SE_DACL_PROTECTED remain set after removal from protected groups
Impact
Former privileged accounts retain stale permissive ACLs outside current OU policy, becoming stealthy attacker pivot targets.
Verification signal
Re-run the detection test and a controlled negative-path test.
Safe correction
Weekly scheduled reconciliation of adminCount=1 objects against current protected group membership, reset and re-enable inheritance
Rollback or recovery
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.

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.

03

Apply the safer control

Before you change production

Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.

Fix commands and configuration

Get-ADObject -LDAPFilter '(adminCount=1)' -Properties adminCount,memberOf
dsacls "DN" /P:N
dsacls "DN" /I:S
04

Verify, roll back or escalate

Verify

Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.

Rollback

Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.

Escalate

Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.

After remediation

Further reading stays below the corrective workflow and is selected by platform, category and shared technical keywords.

Discover more

Connected KBY resources

AdminSDHolder Stale ACLs: Rights That… | Config Traps