AdminSDHolder, SDProp, and Protected Users: The AD Controls Nobody Configures Right

AdminSDHolder. SDProp. The Protected Users group. These are Active Directory's built-in security controls for privileged accounts - and the ones I see most frequently misconfigured, occasionally abused, and almost always misunderstood. They're supposed to protect your Domain Admins, Enterprise Admins, and other Tier 0 accounts. Misunderstood, they leave gaps - and in the wrong hands, AdminSDHolder becomes a persistence mechanism.

What AdminSDHolder Actually Does

AdminSDHolder is an object in every domain (CN=AdminSDHolder,CN=System,...) whose ACL acts as the security template for privileged accounts and groups. A background process called SDProp (Security Descriptor Propagator), running on the PDC emulator, applies that template to every protected object: the protected groups themselves and all of their members, including nested members. The protected groups include Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Print Operators, Backup Operators, Replicator, Domain Controllers, Read-only Domain Controllers, Key Admins and Enterprise Key Admins.

When SDProp processes a protected object, it:

• Sets adminCount=1 on it
• Disables permission inheritance on it
• Overwrites its ACL with a copy of AdminSDHolder's ACL

SDProp runs every 60 minutes by default (configurable via AdminSDProtectFrequency, though there's rarely a good reason to change it). This is why permission changes you make directly on a Domain Admin account keep disappearing - SDProp puts the template back within the hour.

The Misconfiguration Trap: Orphaned adminCount=1 Accounts

Here's the scenario I see constantly:

• Someone adds a service account to Domain Admins for "just one task"
• SDProp marks it adminCount=1, turns off inheritance and stamps on the AdminSDHolder ACL
• After the task, they remove it from Domain Admins
• Nothing cleans up: the account keeps adminCount=1, inheritance stays off, and SDProp simply stops maintaining it

To be clear about what this does and doesn't mean: the account does not keep Domain Admin rights - those came from the group membership, which is gone. What it keeps is a frozen security descriptor. That causes real problems:

• It no longer inherits permissions from its OU. Delegations you add later - helpdesk password resets, new hardening ACEs, your monitoring tool's read rights - silently don't apply to it.
• It's a marker of past privilege. Orphaned accounts are usually former admin or service accounts, often with old passwords, leftover SPNs and rights granted elsewhere. Attackers enumerate adminCount=1 precisely to find them.
• It pollutes your reviews. If you use adminCount=1 to scope privileged-account monitoring, stale entries hide the real ones.

Finding them means comparing adminCount=1 against current recursive membership of the protected groups:

(krbtgt is excluded because it's protected by design.)

Protected Users Group - What It Actually Does

The Protected Users group was introduced with Windows Server 2012 R2. It isn't a permission - it's a set of hardening restrictions applied to its members' authentication. Members get:

• No NTLM authentication - the account can only use Kerberos, so its NT hash can't be passed over NTLM
• No DES or RC4 in Kerberos pre-authentication - AES only
• No Kerberos delegation, constrained or unconstrained
• 4-hour TGT lifetime, with no renewal beyond that
• No credential caching on the device - no cached logon verifier (so no offline logon), and no plaintext delegation through CredSSP or WDigest

Those restrictions are exactly what makes it valuable for admin accounts - and exactly what breaks things if you add the wrong accounts without testing:

• Never add service accounts or computer accounts. Services that need delegation or NTLM will fail.
• Laptops can't log on offline as a Protected Users member - no cached credentials.
• Anything that only speaks NTLM (apps connecting by IP address, older appliances, some NAS devices) stops working for those accounts.
• Admins re-authenticate every 4 hours. A feature, but plan for it.

The second query is the useful one: every human Tier 0 admin account should be in Protected Users. Your break-glass account is the usual exception, so it can still log on if Kerberos is broken.

The Abuse Scenario: AdminSDHolder as a Backdoor

Here's how attackers abuse AdminSDHolder in real incidents:

• The attacker gains Domain Admin rights
• They add an ACE to AdminSDHolder granting an ordinary-looking account they control GenericAll (full control)
• Within the hour, SDProp copies that ACE onto every protected group and every privileged account
• You evict them: remove them from Domain Admins, reset passwords
• Weeks later, the ordinary-looking account uses its full control over the Domain Admins group to add itself back

This is a classic "backdoor through the mechanism." Removing the attacker from groups doesn't help, because the permission lives on AdminSDHolder - and SDProp keeps re-applying it for them.

The good news: SDProp works for you once you fix the source. Remove the rogue ACE from AdminSDHolder and the next SDProp run overwrites the copies on every protected object.

My Detection and Remediation Approach

Here's my standard checklist when reviewing AdminSDHolder and Protected Users in an assessment:

1. Audit AdminSDHolder's ACL

Expect SYSTEM, Domain Admins, Enterprise Admins and Administrators, plus a few built-in groups with narrow property writes (such as Cert Publishers). Anything else - especially a named user or an obscure group - needs an explanation. The best reference is the same query run against a clean lab domain at the same functional level.

If you prefer dsacls, remember it prints friendly names like "FULL CONTROL", "WRITE PERMISSIONS" and "WRITE OWNER" - searching its output for GenericAll or WriteDacl finds nothing.

2. Find Orphaned adminCount=1 Accounts

Use the script from earlier in this post. Disable anything that's no longer needed, and clean up the rest (see "The Fix" below).

3. Review Protected Users Membership

Every human Tier 0 admin should be in it; no service or computer accounts should be. Use the queries in the Protected Users section.

4. Monitor for Changes

• Event ID 5136 (directory service object modified) with nTSecurityDescriptor changes on AdminSDHolder - needs Directory Service Changes auditing and a SACL on the object
• Event ID 4780 ("The ACL was set on accounts which are members of administrators groups") - logged on the PDC emulator when SDProp resets an account's ACL, useful to see what SDProp is touching
• Event IDs 4728, 4732, 4756 - members added to protected groups

The Fix: Cleaning Up an Account Properly

When an account leaves a protected group, removing the membership isn't enough. You also need to clear adminCount and turn inheritance back on:

Then review the explicit ACEs left over from AdminSDHolder and remove any that don't belong - and reset the account's password, since it was privileged while it held that membership.

Final Thought

AdminSDHolder and Protected Users are powerful security features - if you understand how they actually work. Most organizations never look at them after the domain is built. They need ongoing management like any other access control.

My rule of thumb: if you add an account to a protected group, you need a process for removing it cleanly. AD doesn't clear adminCount or restore inheritance when someone leaves a protected group. You have to do it.