AdminSDHolder and SDProp: understanding, auditing and cleaning up protected accounts

How the mechanism works

The CN=AdminSDHolder,CN=System object in each domain holds a reference security descriptor. A process called SDProp, run by the domain controller holding the PDC emulator role (every 60 minutes by default), compares that template with the ACLs of protected accounts and groups. If they differ, it overwrites the protected object's ACL, disables inheritance and sets the adminCount attribute to 1.

Protected groups include Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, Print Operators, Replicator, Domain Controllers and Key Admins, along with the Administrator and krbtgt accounts. Their members, direct or nested, are protected too.

Orphaned adminCount

When an account leaves a protected group, SDProp does not "unprotect" it. adminCount stays at 1 and inheritance stays disabled. As a result, delegations applied at OU level no longer reach the account, which can break helpdesk tasks, and the account keeps showing up as sensitive in tools. Above all, these accounts often point to former administrators whose rights were removed without any clean-up.

Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount, MemberOf, Enabled |
    Select-Object SamAccountName, Enabled, @{n='Groups';e={$_.MemberOf.Count}}

This list then needs to be compared with actual membership of protected groups, nesting included.

AdminSDHolder as a persistence tool

An attacker who has gained high privileges can add an access control entry to AdminSDHolder, for example full control for an inconspicuous account. Within the hour, SDProp pushes that entry to every protected account and group. Even if the ACE is removed directly from Domain Admins, it comes back at the next cycle. It is a simple and effective persistence technique.

Auditing the ACL

Import-Module ActiveDirectory
$dn = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
(Get-Acl "AD:$dn").Access |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType, ObjectType

For detection, enable directory service changes auditing and a SACL on AdminSDHolder: event 5136 will then flag any change to its security descriptor.

Cleaning up properly

1. Confirm the account no longer belongs, even indirectly, to any protected group.
2. Clear adminCount.
3. Re-enable permission inheritance on the object, then review the resulting ACL.
4. Document the change and check after the next SDProp cycle that the account has not been re-protected.

What an audit checks

• non-standard entries in the AdminSDHolder ACL;
• accounts with adminCount=1 that are no longer members of protected groups;
• the dsHeuristics value, if operator groups have been excluded from protection;
• whether change auditing is in place on the object.