I had a discussion with a friend the other day. We were chatting about AD and management tasks when he suddently complained that AD, would require more in-depth knowledge for administration and maintenance. I disagreed as – and that’s kind of my thinking about all technology topics – if you want to be on top of things, you’ll need to learn steadily – and improve your knowledge.Â All products have a certain amount of complexity. As a special example of how “difficult” AD really is, he mentioned “AdminSDHolder”.
If you never got AdminSDHolder, yeah, I realize, that might be a diffcult chapter for AD administrators. Put simple. AdminSDHolder is just a built-in group protection mechanism. It helps you secure your built-in groups. If you once understood how it does it’s job, it’s not that difficult anymore.
I’ll not go into the details, there are good articles on this out there. Two of them are:
- John’s _great_ write-up for the TechNet Magazine: http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx
- Ulf’s explaination why permissions sometimes may disappear: http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx
Put simple, what the protection process does is, look at list of built-in groups to protect and then walk through this list of groups and look at the members and nested groups. For each and every member (users, groups and computers), it compares the security settings (the ACL)Â with a pre-defined object in the directory,Â the CN=AdminSDHolder,CN=System,DC=domain,DC=tld object (hence the fance name).Â If it finds that security is different on the protected group member, it’ll force AdminSDHolder’sÂ ACL back onÂ it, disable permission inheritance on the object and set a magic attribute called “adminCount”of that memberÂ to 1.
The adminCount attribute is there to mark an object as “touched by the AdminSDHolderÂ process”. You can determine all users or groups with ADFind (it’ll point out the DN and the sAMAccountName of the protected objects):
Adfind.exe -b DC=domain,DC=tld -f “(&(objectClass=user)(objectCategory=person)(admincount=1))” sAMAccountName dn
Doesn’t sound too complicated, does it? Well, my friend agreed that the process itself didn’t lookÂ that complicated butÂ if’ve heard not much about it or just sawÂ how “weird” the systemÂ behaved with a couple ofÂ objects and not others, you first might get confused.
What you probably need to know as well is that, once you removeÂ objects from the protected group, ACLs aren’t reseted by default. You’ll need to touch those objects manually and do the following:
- enable permission inheritance so that the objects “applies” the permissions coming from the tree
- adjust the permissions on the object
- reset the adminCount attribute to 0