SDProp vs ADminSDholder

Question

What is the difference between SDProp and ADminSDholder?

Answer 1

SDProp and AdminSDHolder are two parts of the same protection mechanism for highly privileged accounts and groups in Active Directory, but they are different things:

1. AdminSDHolder (object/template)
   • A special object in each domain: CN=AdminSDHolder,CN=System,DC=<domain>,DC=<tld>.
   • Acts as a permissions template for all protected accounts and groups (for example, Domain Admins, Enterprise Admins, Schema Admins, Administrator, etc.).
   • The ACL (permissions) configured on AdminSDHolder defines what the ACL on protected objects should look like.
   • Owned by the Domain Admins group by default; Enterprise Admins, Domain Admins, and Administrators can modify it (subject to ownership/permissions).
   • Permissions inheritance is disabled on AdminSDHolder so that changes to its parent container do not affect it.
2. SDProp (process/task)
   • Security Descriptor Propagator (SDProp) is a background process that runs on the PDC Emulator (PDCE) for the domain.
   • By default runs every 60 minutes.
   • Compares the ACL on AdminSDHolder with the ACL on each protected account and group.
   • If any protected object’s permissions differ from AdminSDHolder, SDProp resets that object’s permissions to match AdminSDHolder.
   • Also responsible for setting adminCount = 1 on protected objects.
   • The interval can be changed (for testing) via the AdminSDProtectFrequency registry value on the PDCE, or SDProp can be triggered manually (for example, via Ldp.exe) without changing the schedule.
3. How they work together
   • AdminSDHolder defines what the security descriptor for protected objects should be.
   • SDProp is the mechanism that enforces that template on all protected accounts and groups on a regular schedule (or on demand).
   • Because SDProp regularly reapplies AdminSDHolder’s ACL, manual permission changes on protected objects are overwritten.
   • Permissions inheritance is disabled on protected objects, so they do not inherit from their OU; instead, their ACL is explicitly set to match AdminSDHolder.

In short: AdminSDHolder is the ACL template; SDProp is the engine that periodically copies that template to protected accounts and groups.

---

References:

• Appendix C: Protected Accounts and Groups in Active Directory
• Reducing the Active Directory Attack Surface
• Troubleshoot insufficient access rights error
• Delegated permissions are not available and inheritance is automatically disabled
• Appendix I: Creating Management Accounts for Protected Accounts and Groups in Active Directory

Answer 2

Hi Ace Jerraldven C. Enoc,

It is very easy to get these two terms mixed up because they are two halves of the exact same security mechanism. They work together to protect your highest-privileged Active Directory accounts (like Domain Admins or Enterprise Admins) from unauthorized permission changes.

Here is the most straightforward way to understand the difference:

1. AdminSDHolder is the Blueprint (The Object)

Think of AdminSDHolder as the master security template. It is an actual physical container object located in your AD domain partition (CN=AdminSDHolder,CN=System...). Its sole purpose is to hold a strict Access Control List (ACL). The permissions set on this object dictate exactly who is allowed to manage your highly privileged accounts.

2. SDProp is the Enforcer (The Process)

The Security Descriptor Propagator (SDProp) is a background process that runs on your primary Domain Controller (specifically, the PDC Emulator role). By default, it wakes up every 60 minutes.

How they work together: Every hour, the SDProp process wakes up, looks at the AdminSDHolder blueprint, and strictly enforces those exact permissions onto every protected account and group in your domain.

If an attacker (or an accidental script) modifies the permissions of a Domain Admin to grant themselves backdoor access, the SDProp process will detect the mismatch, wipe out the unauthorized changes, disable permission inheritance, and reset the account's security back to match the AdminSDHolder blueprint.

I hope this clears up the mechanics of how Active Directory defends its administrative groups. If this explanation was helpful, please click "Accept Answer".

Tracy.