This series of posts focuses on key Active Directory (AD) components that need to be secured in order to ensure AD security is leveled up. this post focuses on permissions on two important objects in AD: the Domain root and the AdminSDHolder object.
Domain Root
Let’s start with the domain root. The domain is the container for all domain objects and on the domain object itself, there are permissions in a similar manner to any object in Active Directory. What makes the Domain root object special is that any permissions set here are inherited by default on objects below it which means that permissions here can affect all domain objects: users, computers, groups, etc. Note that permissions set at the domain level do not apply to AdminSDHolder protected objects, such as Domain Admins and DA members, but can apply to Domain Controllers and Read-Only Domain Controllers.
Since Domain root permission additions and changes apply to all objects (except AdminSDHolder protected objects), domain permissions should not be changed. It is best to perform delegation at the level below this, where the top-level OUs are configured. Yes, I get that this can be a pain, but permission delegation should be performed deliberately and with great attention to detail.
AdminSDHolder
The AdminSDHolder object, contained in the System container in the domain, is effectively a permissions template object populates on protected objects. (like the Domain Admin group and members). Skipping the deep technical details, the permissions on the AdminSDHolder object effectively gets applied to protected objects, inheritance on these objects is removed, and the admincount property is set to 1. For more technical details, I recommend you read Jim’s excellent post here: https://specterops.io/blog/2025/10/31/adminsdholder-misconceptions-misconfigurations-and-myths/
Changes to the permissions on the Domain’s AdminSDHolder object apply to protected objects, so these need to be carefully considered and crafted. we don’t want to inadvertently enable administration of a protected object like Domain Admins by a lower tier group like Server Admins, for example. There are few circumstances where modification of permissions on the AdminSDHolder object is appropriate. One of these we often see relates to password change capability for a password vault service account in order to manage the password for AD Admins.
Summary
With these objects described as such, it’s critical to review the permissions on these objects as they are powerful. There are default permissions that are expected on each of these objects and in most cases, these should remain as configured. Changes to the defaults should be well documented with the purpose of each modifcation so these changes can be removed when they are no longer required.
Recent Comments