AdminSDHolder is quite a subject !

AdminSDHolder – The Container

If you enable the “Advanced Features” in your “Active Directory Users and Computers”,you will see the “System” container. The first child in it is the “AdminSDHolder” container :

AdminSDHolder – The Container

The container is empty, this is normal.

AdminSDHolder – The ACL

The container is empty because his role is to hold ACL’s. This container is the reference ACL’s for all Active Directory protected objects.

In Active Directory, there are some builtin groups that gives a lot of permissions on the domain. These groups evolved with Active Directory versions :

All recursive members of theses groups will have the ACL’s wiped cleaned and a copy of the AdminSDHolder ACL’s with inheritance disabled. This is done by the SDProp.exe that run on the PDCe every hour by default. The SDProp also set the “AdminCount” attribute to 1, this give you an easy way to get them all :

Get-ADObject -Filter {AdminCount -eq 1}

AdminSDHolder – AdminCount – PowerShell

Note : This process is “unmanaged”, if someone leave those high privilege groups, the ACL’s aren’t treated anymore, but aren’t reset either. Those objects then have some custom ACL’s without inheritance that prevent organizational unit ACL to apply on them.

AdminSDHolder – The SDProp Process

As I said, the SDProp.exe run on the PDCe of the domain every hours by default. This a modifiable behavior with this registry key :

Set-ItemProperty -Path HKLM:SYSTEMCurrentControlSetServicesNTDSParameters -Value 60 -Name AdminSDProtectFrequency #In seconds

You can also force a manual trigger with ldp.exe without touching the registry.

AdminSDHolder – Customization of the Scope

By default, the SDProp.exe targets all the recursive users in the groups listed here. If you feel the need to remove a group from this protection mechanism, you can do it with DSHeuristics customization. This page goes in great details about how to do it :

http://www.selfadsi.org/extended-ad/ad-permissions-adminsdholder.htm

Basically, you need to play with a 16 bits attribute to exclude some groups of this process. This page also present a tool do it graphically.

AdminSDHolder – Impacts

As you may already understand, groups or accounts impacted by the SDProp.exe becomes unmanageable by your help-desk or custom delegation you set up in your domain.

This is fine for account or groups that are still in the protected groups, but not for the ones who since left the groups. The best solution to treat “old admins” is to delete those accounts. You can say it’s a bit harsh but you need to understand that if someone once was an “Domain Admins” he could created some objects, and even if he loses his privileges, he still is the owner of the objects he created.

If you still do not want to delete those accounts, you can manually restore their old ACL with a few clicks :

1. Clear the AdminCount attribute
2. Wipe ACLs
3. Enable inheritance
4. Restore default ACLs

Please note that enabling inheritance is not enough, you really need to restore the default ACL’s. Indeed each time you create an Active Directory object, depending on the class, the object get some default ACL’s from the schema. If you don’t, as an example,  the user won’t be able to change his own password. If he tries, he will get an “Access Denied” error.

Active Directory Default Security Descriptor

As I said earlier, the Active Directory Schema contains the default ACL’s for all object class. Each time you create a new object, those ACL’s are copied from the schema to the newly created object. You can find the default ACL’s for each object class with :

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -Filter {ObjectClass -eq 'classSchema'} -Properties defaultSecurityDescriptor

AdminSDHolder – Default Security Descriptor