First published on TechNet on May 07, 2009
here again. After a few years of supporting Active Directory, nearly everyone runs into an issue with
. This object and its AD worker code is used by Domain Controllers to protect high-privilege accounts from inadvertent modification – i.e. if an administrator account was moved into an OU that was being maintained by an delegated OU admin, it makes sure the high-privilege permissions are not stripped away. You can probably think of a few reasons why allowing a member of Enterprise Admins to be monkeyed with is a Bad Thing™.
Anyhoo, the way this works is there’s a special object located at:
Any security descriptors for those groups listed on that object are re-stamped on the user object members every 60 minutes. So you may have run into this where you had made some custom ACL changes on your Administrator user that was a member of some OU, then found an hour later that your changes had disappeared. All by design, all well-and-good. There is also the related
code, which computes and fixes up group memberships for Administrative groups. Both tasks operate only on the PDC Emulator.
So here are the questions Microsoft gets asked most commonly about this system, and where we haven’t always done the best job documenting answers – until now. :-)
How does the AdminSdHolder operation determine whether or not to ACL an account?
It is based on transitively expanding the list of (possibly nested) protected groups. The attribute AdminCount was originally used only as an optimization to improve performance, since it was assumed that regardless of group membership, AdminCount being 1 should trigger protection. However from repro's on Windows Server 2003 and source code review, it appears this is no longer enough to actually trigger the AdminSdHolder operation all on its own.
When a Security Principal is a member of a protected group its Security Descriptor is stamped with the SD of the AdminSDHolder Object for that domain. Also the Security Principal's adminCount attribute is set to value 1. If the SD of the security principal in question already matches the SD of the AdminSDHolder Object, the object is left untouched. Consequently its adminCount value could potentially remain 0. So using AdminCount is a pure mark of whether or not a user is protected is not always a good idea – the group membership is the key.
What is AdminCount, and why is it not being decremented to ‘0’ or ‘<not set>’ when I remove a user from a Protected Group?
AdminCount is an attribute on the user account that is set to 1 on any users being protected by AdminSdHolder. When protected, the user gets this attribute set and the security inheritance bit is removed from their account.
The reason AdminCount isn’t set back to 0 when the user is removed from a protected group is that you told us not to! A survey of customers early on in Windows 2000's design found that they favored deleting a user account after its high-privilege rights were revoked, as the account could have created explicit backdoors before having its rights stripped. Therefore the DC does not remove the AdminCount attribute entry, as it is assumed that the account is going to be disabled or deleted.
If for some reason you didn’t want to get rid of that account after ‘de-admining’ it, you must manually set back to allowing inheritance and set AdminCount to 0, usually through ADSIEDIT.MSC..
Is it possible to make AdminSDHolder code run more or less frequently? What about SDProp?
Yes, with a big caveat.
To change the frequency of AdminSdHolder in SDPRop, set the following through regedit:
The value is a DWORD and you can set a range from 60 to 7200 decimal (it's in seconds). By setting it to 60 you would override the default 60 minute wait time and it would fire every minute. By setting to 7200 it would run every 2 hours.
Note that lowering the default is
except for lab testing due to the potential LSASS performance ramifications in a large environment
I.e. doing this could cause your DC’s processor to spike to very high sustained levels and drastically hurt you.
You can cause SDProp to run once ‘right now’ by using the steps in
to execute FixUpInheritance.
Is there a way to warn administrators that a user being manipulated is covered under AdminSDHolder and SDProp? How do we stop Admins from doing ‘bad’ stuff like this?
Nope, you just gotta know.
As to how you stop Administrators from doing theoretically ‘bad’ stuff – with great power comes great responsibility; AdminSDHolder can only protect you so far from yourself. This is similar to customers who ask us ‘how do I keep administrators from reading all the files on the network?’ The answer is: you cannot. Trust your administrators, bond your administrators, or get different administrators.
Where are all the best articles on AdminSdHolder and related… stuff?
Description and Update of the Active Directory AdminSDHolder Object -
Delegated permissions are not available and inheritance is automatically disabled -
How To Delegate the Unlock Account Right (which is often why you run into this) –