AdminSDHolder Confusion And Admin Actions (Отклик Active Directory: 00002098: SecErr: DSID-03150E49, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0)

Операция Active Directory над srv-vm-ad-10.msk.fbdddk.ru не выполнена. Данная ошибка не допускает повторения попытки. Дополнительные сведения: Insufficient access rights to perform the operation. Отклик Active Directory: 00002098: SecErr: DSID-03150E49, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Posted April 2, 2010
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