AdminSDHolder. SDProp. 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. Instead, they're often the attack vector that gives away the farm.

Why this matters: These mechanisms are invisible by design — and that's exactly how attackers exploit them. You don't see the locked-down ACLs, you don't see the silent SDProp reconciliations. But they're there, silently enforcing or breaking your access control.

What AdminSDHolder Actually Does

AdminSDHolder is a security template in AD that gets applied to protected groups and their members. When you add an account to a protected group (Domain Admins, Enterprise Admins, Schema Admins, etc.), two things happen:

  1. The account gets AdminCount=1
  2. AdminSDHolder's ACL gets applied to the account's ACL

Here's where it gets interesting: AdminSDHolder isn't a static template. It's dynamic — the system periodically compares protected accounts' ACLs to AdminSDHolder's ACL and reconciles them. This reconciliation happens via SDProp (Security Descriptor Propagator).

# Check if an account has AdminCount=1 Get-ADUser "jdoe" -Properties adminCount,adminAccount # Check AdminSDHolder's ACL dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local" | findstr "ADMINISTRATORS"

SDProp runs every 15 minutes by default. It reads AdminSDHolder's ACL and applies it to any account with AdminCount=1 that doesn't match. This is why your carefully crafted permissions keep getting overwritten — SDProp is silently resetting them.

The Misconfiguration Trap

Here's the scenario I see constantly:

  1. Someone adds a service account to Domain Admins for "just one task"
  2. After the task, they remove it from Domain Admins
  3. The account still has AdminCount=1 and the locked-down AdminSDHolder ACL
  4. The account now has excessive permissions but isn't visible in group membership queries

This is the orphaned protected account — it looks clean in group membership, but under the hood, it still has all the permissions of a Domain Admin.

# Find accounts with orphaned AdminCount=1 Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount,enabled | Where-Object { $user = $_ $groups = Get-ADGroup -Filter * | Where { ($_ | Get-ADGroupMember | Select -Expand DistinguishedName) -contains $user.DistinguishedName } return -not $groups } | Select name,samAccountName,adminCount

These accounts are invisible to standard group membership enumeration. They're the "stealth admin" accounts that attackers love because they don't show up in your standard privileged access reviews.

Protected Users Group — What It Actually Does

The Protected Users group was introduced in Windows Server 2012 R2 to provide additional protection for sensitive accounts. But its name is misleading — it doesn't protect users, it protects against certain attack types.

Protected Users gets you:

  • No caching of credentials on domain controllers
  • Refuses Kerberos delegation
  • Requires AES encryption for Kerberos (no RC4 fallback)
  • Prevents NTLM authentication
  • Disables token groups for group membership evaluation (which can break some applications)

That last one is the killer — token groups means that when you log in, Windows evaluates all your group memberships and includes them in the access token. Protected Users disables this, which means applications that rely on group membership for authorization will break.

# Check if a user is in Protected Users Get-ADGroupMember "Protected Users" | Where { $_.ObjectClass -eq "user" } | Select name,samAccountName # Check what SID is in Protected Users (some implementations use SID instead of group) Get-ADUser -Filter {SIDHistory -like "*S-1-5-21-*-525*"} | Select name,SIDHistory

Many organizations enable Protected Users and add all their admins to it — without testing application compatibility first. The result: help desk tickets for users who can't access shared drives, email, or line-of-business applications.

The hidden risk: Protected Users sounds like a protection, but it's really just blocking certain attack techniques. It doesn't prevent credential theft, lateral movement, or other common attack vectors.

The Abuse Scenario: AdminSDHolder ACL Manipulation

Here's how attackers abuse AdminSDHolder in real incidents I've worked:

  1. Attacker gets Domain Admin access
  2. Attacker adds themselves to a protected group (temporarily or permanently)
  3. Attacker modifies AdminSDHolder's ACL to include their own permissions
  4. When SDProp runs, it propagates the modified ACL to all protected accounts
  5. Attacker has persistent backdoor access even after being removed from the protected group

This is a classic "backdoor through the mechanism" attack. You remove the attacker from Domain Admins, thinking you've secured the environment — but because they modified AdminSDHolder, their permissions are still being propagated to all protected accounts.

# Check who has modify permissions on AdminSDHolder dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local" | findstr /C:"GenericAll" /C:"WriteOwner" /C:"WriteDacl" # Look for unauthorized permissions dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local" | findstr /C:"ALLOW" /C:"DENY"

My Detection and Remediation Approach

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

1. Audit AdminSDHolder ACL

# Export and analyze AdminSDHolder ACL dsacls "CN=AdminSDHolder,CN=System,DC=corp,DC=local" > admindsacls.txt # Look for unexpected permissions findstr /C:"GenericAll" /C:"WriteDac" /C:"WriteOwner" admindsacls.txt

2. Find Orphaned AdminCount=1 Accounts

# Query for accounts with AdminCount=1 not in any protected group Get-ADUser -Filter {adminCount -eq 1} -Properties adminCount,enabled | Where-Object { $user = $_ $protectedGroups = "Domain Admins","Enterprise Admins","Schema Admins","AdminSDHolder" $memberOf = Get-ADGroup -Filter * | Where { try { $_ | Get-ADGroupMember -ErrorAction Stop | Select -Expand DistinguishedName } catch { $null } } | Where { $_.DistinguishedName -eq $user.DistinguishedName } return [string]::IsNullOrEmpty($memberOf) } | Select name,samAccountName,adminCount

3. Review Protected Users Membership

# Who is actually in Protected Users? Get-ADGroupMember "Protected Users" -Recursive | Select name,samAccountName,ObjectClass # Check if any non-admin accounts are in Protected Users Get-ADGroupMember "Protected Users" | Where { $_.ObjectClass -eq "user" } | ForEach-Object { $user = $_ $isInProtectedGroup = Get-ADUser $user -Properties memberOf | Select -Expand memberOf | Where { $_ -match "Domain Admins|Enterprise Admins|Schema Admins" } if (-not $isInProtectedGroup) { $user.name + " is in Protected Users but not a protected group" } }

4. Monitor SDProp Activity

SDProp itself doesn't log to the event log, but you can monitor its impact:

  • Event ID 4738 (User Account Changed) — especially on protected accounts
  • Event ID 5136 (Directory Service Object Modified) — look for modifications to AdminSDHolder
  • Unexpected changes to protected group membership

The Fix: Not Just Removing from Groups

When removing an account from a protected group, you must:

  1. Remove from the protected group
  2. Set AdminCount=0
  3. Clear the locked-down ACL from AdminSDHolder
# Remove from Domain Admins (or other protected group) Remove-ADGroupMember "Domain Admins" -Members "serviceaccount" -Confirm:$false # Reset AdminCount Set-ADUser "serviceaccount" -Replace @{adminCount=0} # Reset ACL to inherit from parent (this removes AdminSDHolder's locked-down permissions) dsacls "CN=serviceaccount,OU=Service Accounts,DC=corp,DC=local" /G "Everyone:GA" # Or use: icacls to reset ACL inheritance

Final Thought

AdminSDHolder and Protected Users are powerful security features — if you understand how they actually work. Most organizations enable them and assume they're "done" from a security perspective. They're not. These mechanisms require ongoing management, just like any other access control system.

My rule of thumb: If you add an account to a protected group, you must have a process for removing it cleanly. AdminCount=0 isn't optional — it's required. The system doesn't automatically reset it when you remove someone from the group. You must do it manually.

Warning: And if you're going to use Protected Users, test everything first. The token groups disable will break applications. You'll find out during your next incident response when the attacker has access to everything and you're wondering why Protected Users didn't protect you.