Five common questions about AdminSdHolder and SDProp

  • [アーティクル]

Ned here again. After a few years of supporting Active Directory, nearly everyone runs into an issue with AdminSdHolder. 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 ‘<not set>’ 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_MACHINESYSTEMCurrentControlSetServicesNTDSParameters]
"AdminSDProtectFrequency"= <something>

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.

- Ned ‘Turboprop’ Pyle

Comments

  • Anonymous
    May 07, 2009
    PingBack from http://www.netdeluxo.com/blog/blogs/ask-the-directory-services-team-five-common-questions-about/

  • Anonymous
    May 07, 2009
    The comment has been removed

  • Anonymous
    May 08, 2009
    The comment has been removed

  • Anonymous
    May 08, 2009
    You are right about SDPROP - I was trying to oversimplify here without going into the actual undocumented worker that makes up AdminSDholder, but ended up making it sound like they were one in the same - in reality they are related, but only in passing. I've tweaked the article a bit to make more sense, let me know what you think. I'm trying out the AdminCount part right now in a repro. From looking at source code (rather than trusting an internal doc), I am beginning to suspect that you are right - once upon a time this might have been the case, but no longer since at least 2003. I'll change that part too if needed. Thanks Tony!

  • Anonymous
    May 08, 2009
    Yep, I cannot get it to flip with just AdminCount=1 anymore. Nice catch Tony, I've updated that piece as well.

  • Anonymous
    May 11, 2009
    The comment has been removed

  • Anonymous
    May 11, 2009
    The comment has been removed

  • Anonymous
    July 10, 2014
    I ran into a strange one recently. I have been trying to delegate some permissions to people to manage

  • Anonymous
    September 19, 2014
    This blog post is a study guide to help you to prepare Microsoft MCP 70-413 : Designing and Implementing

  • Anonymous
    December 11, 2014
    Hey y’all, Mark, Tom and the AskPFEPlat crew back for our last mailbag of 2014. It’s getting