Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2006-05-16) AdminSDHolder

Posted by Jorge on 2006-05-16

Every hour, the Microsoft Windows domain controller that has the primary domain controller (PDC) emulator operations master role verifies the ACLs on members of these administrative groups and compares them to the ACL on the AdminSDHolder object. If the ACL that is on the AdminSDHolder object is different, the ACLs on the members of the administrative group are reset to match the ACL on the AdminSDHolder object.

More information (not all may apply to your situation!):


The adminsdholder process only looks at users and groups that are defined in AD as protected objects. As mentioned in MS-KBQ817433 – "Delegated permissions are not available and inheritance is automatically disabled" it is possible to include or exclude some of the default admin groups (account operators, print operators ,etc.) The process that checks objects against the adminSDHolder object only looks at that definition of protected objects and in case of groups it will also look at its members. It resets the DACL to match the DACL of the adminSDHolder object, sets the admincount attribute value to 1 and disables permission inheritance. The group membership of a protected group is the criteria the process looks at, not the attribute value of 1. The admincount attribute is just an administrative measure for the process that says "been here", nothing else.


To make a protected member of a protected group a non-protected member you need to:
* remove his membership from the protected group
* enable inheritance again on the member
* set the admincount attribute to 0 or to <not set>

What is said is that by removing the member from a protected group, inheritance will not be changed and the admincount attribute will also not be changed automatically. All must be changed manually and when reverting the object back to a non-protected object it is best to do all three!

Also see:


Once in thread somebody asked: "Is it possible to add your own custom groups within the protection scope of the AdminSDHolder and the process that uses it?"

Well… by default the answer is NO!


There is a way however, but that way HAS A CATCH you need to be aware of!!! (never tried it myself but I think it will work).
How to do that?

  1. Take a protected group (weakest if possible)
  2. Create a distribution group with a name like "Custom_Protected_Groups_Definition" and make that a member of the actual protected group
  3. Put all users and groups directly into the distribution group that need to be protected by adminSDHolder

Now what will happen?
The adminSDHolder process sees the memberships (transitive included) and protects them.
When a user logs on, he will be a member of the distribution group "Custom_Protected_Groups_Definition" but the SID of the actual (security) protected group will not be in the access token of the user.
If a distribution group is a member of a security group, the members of the distribution group will not be transitive security members of the security protected group as the distribution group blocks the security group membership


Doing this will remove the security group membership block and the users/group will suddenly get the SID of the protected security group in their access token and will have too many permissions! Also make sure only highly trusted persons manage that distribution group!


Is this "weird approach" recommended or a best practice? NO!


So what IS a best practice to protect custom powerful groups?

It is called: "Delegation of Control" (or only allow those persons manage those objects they should manage!)

As you may know it is possible to create an additional OU and configure permissions (if needed) so that only those admins that should manage those objects are able to manage those objects!


You can ask yourself: why are those groups you want to protect in the OU where stuff has been delegated? If they are protected the delegates will not be able to manage them, so you might as well put them in a separate OU and if needed configure other DACLs.

Remember that an OU structure is based upon three things:
(1) Delegation of control
(2) Hidding objects
(3) Applying GPOs

The groups you want to protect could fit in (1) and/or (2)

* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
############### Jorge’s Quest For Knowledge #############
######### ########


2 Responses to “(2006-05-16) AdminSDHolder”

  1. Marcus Oh said

    your posts rock, jorge… 🙂

  2. dloder said

    Exchange 2010 RC1 and AdminSDHolder

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: