One of the alert joeware fans out there sent me a link to the following TechNet story that utilizes AdFind.
http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx
While the article is a bit rough, for example sdprop isn’t responsible for AdminSDHolder[1] it is an ok article for a general sort of conceptual overview on how it works[2] and there is some good info summary that is useful to have in a single place. I will try to point out specific things that aren’t right that could bite you though.
First “this could bite you” issue is that ProtectAdminGroups (PAG see note [1]) does not CLEAR the inheritance flag on the ACL… All the process does is compare the WHOLE Security Descriptor from the AdminSDHolder object to the object that should be “protected”. If the size or the binary “string” varies in any way, the Security Descriptor on the object is overwritten by the Security Descriptor from the AdminSDHolder object[3]. This means that if you set the AdminSDHolder object to inherit permissions, any object that is updated with PAG will also be set to inherit since the inheritance is set by a flag in the DACL portion of the Security Descriptor. This is important to note because if someone screws up and sets the AdminSDHolder to inherit perms, your protection is effectively gone that is to save your butt when you accidently move an admin user or group into an OU that someone else has rights to make certain modifications. For example, blow the Security Descriptor on AdminSDHolder, then accidently move Administrator into an OU that has granted (RE)SET PASSWORD to local admin XYZ and now local admin XYZ can take over the administrator group.
The second issue is “The ability to control groups protected by AdminSDHolder is enabled by modifying the dsHeuristic flag. This is a Unicode string in which each character contains a value for a single domain-wide setting.”. The dsHeuristic flag is actually forest-wide, not domain wide. The attribute is in the configuration container and that container is pretty much only used for forest wide configurations.
Third issue is an AdFind query… Specifically “Adfind.exe -b DC=domain,DC=com -f "adminCount=1" DN”. There are actually two issues here, the first will bite you, the second won’t bite you but is technically incorrect. The bite you issue is that admincount=1 is a very inefficient filter. That attribute isn’t indexed so this query would end up forcing the DC to enumerate every single object in the domain and looking at that value to determine which ones to return. If you want to find out what users are impacted, use “&(objectcategory=person)(objectclass=user)(admincount=1)”, if you want to find what groups, use “&(objectcategory=group)(admincount=1)”. The second issue in this command is the use of DN… DN isn’t an attribute, if you just want DN’s, specify –dn, not DN. It actually works because AdFind is asking AD to return the DN attribute which doesn’t exist so only the DN gets output. By default the DN is always returned and AdFind displays it for you. Will this hurt anything??? Nope. But it could confuse people if they are trying to understand the command.
The fourth issue is another AdFind query… Specifically “Adfind.exe -b DC=domain,DC=com -f "(&(objectclass=group)(admincount=1))" DN”. Until Windows Server 2008 the objectclass attribute isn’t indexed so just using objectclass in the filter can be inefficient. The efficient form of this query is “(&(objectcategory=group)(admincount=1))”.
The fifth issue is “When a user is removed from a protected group, the adminCount attribute on that user account is changed to 0.”. Last I recall looking, this wasn’t the case. You took someone out of the group, this would stay set and the Security Descriptor would still reflect AdminSDHolder. All manual cleanup. Possibly in later versions of the OS maybe ADUC is smart enough to do this for you, but it isn’t part of the PAG process. Even if it were, it wouldn’t help anything, nothing in the OS is fired based on that attribute value. The OS does a scan of protected groups each run of PAG and does its work based on that, not the value of adminCount.
Obviously all of the stuff about making SDProp run at different rates is moot now given the info above.
Hmm on second thought, that article is rougher than I initially thought. 😉
joe
[1] I once thought that as well but not for some time. There is specific code and an internally scheduled task that is responsible for AdminSDHolder all by itself which I will just call ProtectAdminGroups as I don’t know if it has any other name and in Windows Server 2008 R2 they add a new control access right called Run Protect Admin Groups Task (and an associated RootDSE Mod – http://msdn.microsoft.com/en-us/library/dd305198(PROT.13).aspx). Regardless it definitely isn’t SDPROP. SDPROP is used for fixing up ACL inheritance and when moving objects about. I may take some time and sit down and write up how the AdminSDHolder functionality really works at some point, but not today. The ProtectAdminGroups task does run every 3600 seconds and only on the PDC though…
[2] Don’t be using this article to try and show how technically brilliant you are when interviewing (either side of the interview) because the other side may really know how it works and you could 1) End up looking like an Idiot 2A) Not get the job or 2B) Turn away a potential employee who actually knew what they were talking about. If, for example, you interviewed me and asked me what process was responsible for adminSDHolder ACL updates you would never hear me say SDPROP unless it was… It is actually this but some people think it is SDPROP.
[3] This is much easier and less overhead than doing an ACE by ACE and flag by flag compare of each DACL. And note… it is called Admin”SD”Holder… not Admin”DACL”Holder…
