What is AdminSDHolder Object and how admincount attribute is associated with it? How can you list all the affected objects?

What is AdminSDHolder Object and how admincount attribute is associated with it? How can you list all the affected objects?


Active Directory contains a mechanism to protect the user accounts and groups that are members of administrative groups. Also, the administrative groups are protected, not just their members. Every hour, the domain controller that holds the PDC master role in the domain checks that the permission lists and inheritance setting of these user accounts and groups are identical to the permission list and inheritance setting of a special AdminSDHolder object. The PDC master modifies any differing permission list, so that it will be again identical to the permission list of AdminSDHolder.
Users and groups that are protected with this mechanism are identified with the adminCount attribute value of 1. The PDC master sets this attribute value during its hourly check for all new users and groups that have become members of protected groups during the last hour. You can list all the affected objects to a file, using a command such as the following:

ldifde -f prot.txt -d DC=sanao,DC=com -r (adminCount=1) -l dn

In AD2000, the protected groups are Enterprise Admins, Schema Admins, Domain Admins, and Administrators. AD2003 extends the list (as does Windows 2000 SP4) by adding Account Operators, Server Operators, Print Operators, Backup Operators, and Replicator. In addition, Administrator, the Domain Controllers group (but not its members), and krbtgt are protected. Consequently, account operators can no longer modify their own accounts or the accounts of other account operators.
If a user is removed from a protected group, the hourly permission check (and the possible restoration) that the PDC master performs stops applying to the user object. The PDC master does not restore the old permission entries that existed perhaps six months earlier, before the user was added to the protected group. You must manually specify any permission or inheritance settings you want after the removal from the group. In addition, the adminCount attribute is probably not cleared automatically, so you might want to do that manually. It does not seem to hurt to still have that attribute value set, but it's better to clear it.

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:

cn=adminsdholder,cn=system,dc=contoso,dc=com

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 SDProp 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. :-)

Question: How does the AdminSdHolder operation determine whether or not to ACL an account?

Answer: 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.

Question: What is AdminCount, and why is it not being decremented to ‘0’ or ‘’ when I remove a user from a Protected Group?

Answer: 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..

Question: Is it possible to make AdminSDHolder code run more or less frequently? What about SDProp?

Answer: Yes, with a big caveat.

To change the frequency of AdminSdHolder in SDPRop, set the following through regedit:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"AdminSDProtectFrequency"=

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 NOT recommended 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 KB 251343 to execute FixUpInheritance.

Question: 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?

Answer: 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.

Question: Where are all the best articles on AdminSdHolder and related… stuff?

Answer:

• Description and Update of the Active Directory AdminSDHolder Object - KB 232199.
• Delegated permissions are not available and inheritance is automatically disabled - KB 817433.
• How To Delegate the Unlock Account Right (which is often why you run into this) – KB 294952.
• AdminSdHolder Open Specification Document - 3.1.1.6.1 AdminSDHolder.
• Michael B. Smith has an excellent and very readable article on his blog here.

And that’s that.