What is AdminSDHolder?

Definition

AdminSDHolder is a special object in every Active Directory domain (CN=AdminSDHolder,CN=System,DC=...) whose security descriptor (ACL) is automatically re-applied to all members of certain protected groups (Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, Print Operators, etc.) every 60 minutes by a process called SDProp (Security Descriptor Propagator).

The purpose: ensure that privileged accounts always have a strict, consistent ACL, regardless of attempts to modify their permissions.

In simple terms:

AdminSDHolder is the template that AD copies onto privileged accounts every hour. If attackers modify the template, they modify every privileged account.

---

Why AdminSDHolder Matters

• It enforces a baseline ACL on Tier 0 accounts.
• Modifying AdminSDHolder is one of the most powerful AD persistence techniques.
• Many environments don't monitor AdminSDHolder closely.
• The adminCount=1 attribute marks accounts that are (or were) under SDProp protection.

---

How SDProp Works

1. Every 60 minutes (configurable), the PDC Emulator runs SDProp.
2. SDProp checks all members of protected groups.
3. For each member, it sets adminCount=1 and overwrites their ACL to match AdminSDHolder.
4. The original ACL on the user object is replaced.

This protects against subtle ACL modifications on privileged accounts — but only if AdminSDHolder itself is not tampered with.

---

Protected Groups (Default)

• Account Operators
• Administrators
• Backup Operators
• Domain Admins
• Domain Controllers
• Enterprise Admins
• Print Operators
• Read-only Domain Controllers
• Replicator
• Schema Admins
• Server Operators
• Key Admins / Enterprise Key Admins (newer)

---

How Attackers Abuse AdminSDHolder

1. ACL Backdoor

Attacker with sufficient rights modifies AdminSDHolder's ACL to grant themselves (or an attacker-controlled account) Full Control or specific dangerous rights (Reset Password, Write Members, WriteDACL).

Within an hour, every protected account (including Domain Admins) has the attacker's ACE on their object.

The attacker can now:

• Reset Domain Admin passwords.
• Modify Domain Admin group memberships.
• Persist even after detection — removing membership doesn't remove the ACE; SDProp re-applies it.

2. Stale adminCount=1 Accounts

Accounts that were once members of a protected group keep adminCount=1 and the strict ACL even after removal. These are sometimes ignored by access reviews because they're "no longer privileged" — but ACL inheritance issues can leave them with elevated permissions.

3. Detection Evasion

Many SIEMs alert on group membership changes but not on AdminSDHolder ACL changes — making this a relatively quiet persistence path.

---

Real-World Examples

1. Persistent Backdoor

After reaching Domain Admin, attackers add Full Control for an attacker-controlled account on AdminSDHolder. They remove themselves from Domain Admins to avoid detection. SDProp continues to grant their account control over every protected user every hour.

2. Subtle Right Grant

Attacker grants Write Members on AdminSDHolder for a help desk group. The help desk group can now add anyone to Domain Admins indirectly via SDProp-applied rights — even though they appear to be standard help desk.

3. adminCount=1 Stale Account

A former service desk lead was once a member of Account Operators. They left the role years ago, but adminCount=1 remains. ACL inheritance on their object differs from peers, leaving them quietly more privileged.

---

Best Practices

1. Monitor AdminSDHolder ACL changes — Event ID 5136 (Directory Service Changes) for AdminSDHolder.
2. Audit AdminSDHolder ACL monthly. Compare to a known-good baseline.
3. Alert on any adminCount change on user objects.
4. Audit adminCount=1 accounts that are not currently members of protected groups (stale).
5. Reset ACLs and adminCount on accounts no longer privileged.
6. Restrict who can modify AdminSDHolder (only forest-level admins).
7. Include AdminSDHolder in change management. Any modification should require Tier 0 change ticket.
8. Backup the AdminSDHolder ACL for restoration.
9. Review SDProp interval — default 60 minutes is usually appropriate.
10. Test detection — modify AdminSDHolder ACL in a lab and verify alerts fire.

---

AdminSDHolder Security Checklist

• AdminSDHolder ACL baselined and monitored?
• Event ID 5136 alerts for AdminSDHolder modifications?
• adminCount=1 accounts inventoried and validated?
• Stale adminCount=1 accounts cleaned up?
• AdminSDHolder modifications subject to Tier 0 change control?
• Periodic comparison to baseline ACL?

---

How Forestall Helps

Forestall monitors AdminSDHolder and SDProp-impacted objects continuously:

• Baselines the AdminSDHolder ACL and alerts on any change.
• Identifies adminCount=1 accounts not currently in protected groups.
• Maps how AdminSDHolder ACEs propagate to every protected account.
• Surfaces persistence-class backdoors that traditional access reviews miss.

---

Frequently Asked Questions

Why does SDProp exist?

To prevent admins (or attackers) from quietly weakening ACLs on privileged accounts. Without SDProp, individual permissions could drift away from the secure baseline.

How do I see SDProp's effect?

adminCount=1 on user objects, and ACLs that match AdminSDHolder rather than parent OU inheritance.

Can I customize the SDProp interval?

Yes, via the dsHeuristics attribute, but the default 60 minutes is appropriate for most environments.

Are protected groups configurable?

Mostly fixed by AD design, but dsHeuristics allows excluding some groups (Account Operators, Server Operators, etc.). Excluding them weakens protection — usually not recommended.

Is AdminSDHolder a substitute for Tier 0 isolation?

No — it's a backstop. Strong tiered administration prevents modifications in the first place.

---

Conclusion

AdminSDHolder is one of Active Directory's most important — and most under-monitored — protection mechanisms. Its dual nature (a control that hardens privileged accounts, and a backdoor that propagates attacker-granted ACEs) makes it both essential and dangerous. Continuous monitoring, ACL baselining, stale-account cleanup, and tight change control turn AdminSDHolder into a strong defensive ally rather than a hidden persistence path.