AdminSDHolder: Misconceptions, Misconfigurations, and Myths

TL;DR: This blog is the brief version.

I love delving into ancient history. The Fall of Troy, The Founding of Rome, The Burning of Rome, Active Directory, etc. They say history is written by the winners, but who really wins when it comes to Active Directory Domain Services (AD DS)? The attackers? 

History is full of mysteries, inaccuracies, and lessons never learned. Such is the case with Active Directory’s admin protection mechanism: AdminSDHolder. I dug into the history of this curio that is critical to the security of Active Directory, yet oft misunderstood, occasionally abused, and misconfigured time and again. What I found are dozens of misconceptions and common misconfigurations, many of which are rooted in Microsoft’s own incorrect documentation. Over time, the inaccuracies in Microsoft’s documentation on AdminSDHolder have been spread farther than the British Empire to blogs, products, and documentation. History has indeed repeated itself, but we’re going to get to the source: the source code.

AdminSDHolder is an object and associated process in AD DS that helps protect specific sensitive and highly privileged accounts from being manipulated by less privileged accounts. Without AdminSDHolder, members of the Account Operators could add themselves to the Domain Admins group directly. If not for AdminSDHolder, any account delegated permissions at the root of the domain or in the wrong neighborhoods of the domain hierarchy would be able to compromise the forest without pause. AdminSDHolder is the reason why administrative accounts in AD, by default, do not inherit permissions and have a more restrictive DACL than everything else.

I wrote a 150+ page whitepaper on the topic of this important Active Directory feature called AdminSDHolder: Misconceptions and Misconfigurations (Notice I Didn’t say SDProp). If that seems too long for your tastes, here are most of the spoilers.

Whitepaper Spoilers

1. AdminSDHolder is both an AD object and a background task process that Microsoft designed to protect highly privileged security principals from direct DACL manipulation by lower-privileged principals
2. SDProp does not have any direct relationship to AdminSDHolder. Yes, you heard me correctly, SDProp does NOT apply the AdminSDHolder security descriptor, even though Microsoft’s documentation (incorrectly) states it does
3. The majority of defaults around AdminSDHolder are reasonable
4. Once an object is privileged, it should always be treated as privileged
5. Direct association with a protected object is the trigger for applying AdminSDHolder protection, not adminCount
6. AdminCount is not a reliable method to determine privileged status
7. The AdminSDHolder background task can only protect objects in its own domain
8. AdminSDHolder protections are not permanent if an attacker has control over a principal that can modify the AdminSDHolder security descriptor
9. The members of the Domain Controllers and Read-Only Domain Controllers groups are purposefully excluded from being protected
10. Modifying dSHeuristics has historically been a perilous journey of mainly decreasing AD security defaults, at least up until KB5008383. Don’t weaken security by removing groups from AdminSDHolder protection
11. The default DACL_Protected flag on AdminSDHolder is there for a good reason
12. Be wary of any changes to AdminSDHolder’s DACL that decrease security for privileged accounts, even if Microsoft software tries to make that change
13. AdminSDHolder can generally protect computer objects and computer-derived objects like (g)MSAs, but not if they are members of an excluded group
14. Inherited ACEs on security descriptors are not authoritative for add, modify, or replication purposes. SDProp’s job is to run on every DC to handle the propagation of inheritable ACEs any time an object’s security descriptor is modified or the object is moved
15. AdminSDHolder does not protect all Tier Zero security principals and even if it could, non-DACL-based attack paths would likely still exist. BloodHound can assist with finding attack paths to Tier Zero for instances where AdminSDHolder cannot or is not designed to protect
16. Not everything on the Internet is correct

BloodHound v8.3.0 includes new features to help users understand which user, group, and computer nodes are AdminSDHolder-protected. When data from SharpHound v2.8.0 or newer is ingested, the entity panel of these nodes will include the AdminSDHolder Protected boolean property. The ProtectAdminGroups non-traversable edge shows the relationship between the AdminSDHolder container node for a domain and the objects it protects. Three new custom queries help BloodHound users discover Tier Zero nodes that are not AdminSDHolder Protected, the Location of AdminSDHolder Protected Nodes, and the ProtectAdminGroups edge relationship. Additionally, BloodHound Enterprise includes updated remediation guidance for DACL-based findings.

Download AdminSDHolder Misconceptions and Misconfigurations: Notice I Didn’t Say SDProp?