In Active Directory default, a set of High-Privileged accounts and groups is created when you create your domain. They are often called Protected Groups/Users.
From the beginning at Windows 2000 Server there were four protected groups:
Administrators
Domain Admins
Enterprise Admins
Schema Admins
In Windows 2000 SP4 and Windows 2003 Server they added a bunch of Groups and two user accounts:
Administrator
Krbtgt
Backup Operators
Cert Publishers (removed in Windows 2003 Server SP1)
Domain Controllers
Print Operators
Replicator
Server Operators
Account Operators
And in Windows 2008 Server they added:
Read-Only Domain Controllers
And one last thing, in a hotfix for Windows 2000/2003 Server the ability to remove a few groups as protected groups was enabled:
Account Operators
Server Operators
Print Operators
Backup Operators
This is done with the help of the dsHeuristic attribute flag.
http://support.microsoft.com/?id=817433
So, what is so special to know about protected groups except that they have high privileges and the most of them should almost never be used?
Those who have a delegated Organizational Unit structure may have noticed that every hour the specific delegated rights disappear for some of the admins and create a headache. This is what this post is all about. The AdminSDHolder, SDProp and adminCount misunderstandings.
AdminSDHolder
The AdminSDHolder is an object that exists in all Active Directory Domains. It is stored in the Domain NC System container, in my domain the DN is: CN=AdminSDHolder,CN=System,DC=corp,DC=secid,DC=se
The AdminSDHolder container contains a Master Security Descriptor for the protected groups/users in Active Directory. It runs in a background task in the LSASS process every 60 minutes on the DC holding the PDC Emulator FSMO role.
When the AdminSDHolder runs, it transitively expands the list of protected groups and all its nested groups (security and distribution) and compares the SD for member groups and users with its own Master SD. If there is a mismatch, the ACLs from the AdminSDHolder will be copied and enforced on the object. Inheritance from parent delegates is also disabled to keep consistency even if the object is moved to another location in the directory.
The AdminSDHolder object itself also has inheritance disabled to be protected from parent delegates and has restricted ACLs. Since the AdminSDHolder is not a group object, we can’t actually see the SD ACLs for protected groups or users in the GUI editor. Which also means that we can’t change them IF we would like to do that. For this we would need to use dsacls.exe in a command-line. After it has been propagated to the protected objects you can verify this in the ACL on the objects.
The interval for the AdminSDHolder process could be changed on the PDC Emulator DC.
Edit the regkey: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\ AdminSDProtectFrequency
You can set a value in seconds 60-7200 (1 minute to 2 hours). If it doesn’t exist create it.
This is not recommended to do in a production environment because it can create performance issues on LSASS process (CPU spikes).
A better option would be to trigger the AdminSDHolder process once by using LDP.exe. Run the LDAP modify operation runProtectAdminGroupsTask:
dn:
changetype: modify
add: runProtectAdminGroupsTask
runProtectAdminGroupsTask: 1
By running this on the PDC Emulator DC it will trigger the process to run, on other DCs nothing will happen.
http://msdn.microsoft.com/en-us/library/dd305198.aspx
SDProp
Security Descriptor Propagator Update is a background task that is run on all DCs. Its purpose is to handle the ACE inheritance on objects. Inherited ACEs isn’t replicated so it’s up to the SDProp demon on every DC to propagate them.
Microsoft documentation:
In Active Directory, SDs can contain ACEs that are inheritable. Thus, modifying the SD on an object can imply a change in the SDs of descendant objects (either by adding or by removing such an inheritable ACE). In order to propagate the changes of inheritable ACEs to descendant objects, each DC runs a background task called the Security Descriptor Propagator Update task. By default, this task is triggered by the following conditions:
- Any modification (originating or replicated) of the nTSecurityDescriptor attribute of any object, except for those modifications done by the Security Descriptor Propagator Update task. Such an object is said to have caused a propagation event.
- Any modification of the DN of an object that results in the object having a different parent, except for those cases where the new parent is a Deleted Objects container. Such an object is said to have caused a propagation event.
http://msdn.microsoft.com/en-us/library/dd350247.aspx
It’s very common that people say that it’s the SDProp that only run on the PDC Emulator DC and does all the comparison for protected objects. And they recommend to use the fixupInheritance operational attribute to trigger the AdminSDHolder propagation. For example the Best Practices for Securing Active Directory white paper published April 2013.
Since the AdminSDHolder is a own background process that triggers the SDProp after the comparison has been made and the new SD has been enforced the fixupInheritance only triggers the SDProp to do its standard procedure, recalculate inherited permissions on all descendant objects. But protected objects doesn’t have inheritance enabled and it doesn’t work triggering the operational attribute.
http://msdn.microsoft.com/en-us/library/cc223299.aspx
adminCount attribute
When a group or user is stamped with the new SD the attribute adminCount gets a value of 1, this is also called the SD Stamp.
When a user or a group becomes a member of a protected group directly or by nested groups (Security and Distribution) it is also considered as a protected object and the SD is changed.
And here is where some problems can occur. If you have done a special delegate to an admin account that is member of e.g. Domain Admins. The permissions on that account will be changed every 60 minutes. If you want to change the permissions you have to do it on the AdminSDHolders template using dsacls.exe. But be careful, the changes is made for all protected objects.
If the user is removed from a protected group the adminCount flag won’t be reset to 0 and the SD won’t either be reverted back to its default. You have to manually reset the flag in ADSI Edit or Attribute Editor and turn on inheritance on the object.
If you search for objects with the adminCount object flag set to 1 you will get a list of objects that is or has been a member of a protected groups. If you want to know for sure if it’s still a member, you have to expand the protected groups and the nested groups for all sub members.
The reason for the member object is not reverted back to its default delegation is that if e.g. a user no longer is trusted to be a domain admin it should be disabled/deleted because you don’t know for sure if that account has implemented backdoors.
One last thing, if the user already has an identic SD configured for some reasons, nothing will be changed and the adminCount will still be 0.
Summarizing
The AdminSDHolder and its components is an important part of security in Active Directory. It provides consistency of the Security Descriptor for highly-privileged groups and user accounts. It provides protection against accidental delegation of admin accounts if the objects is moved around or a permission is set on the parent OU. It also has the same SD on itself for the same protection.
It is the AdminSDHolder that does the evaluation and not SDProp, it is only triggered afterward since the ACL inheritance flag is changed on the SD. When objects SD is changed by AdminsSDHolder it gets the adminCount attribute flag set to 1.
The SD is copied and not inherited.
Picture this: the support guys shouldn’t be able to reset the password of user accounts that is member of e.g. the Domain Admins group. If the accounts is moved around they won’t inherit the permissions from parent objects and gives us some protection against privilege escalation.
Common issues:
http://support.microsoft.com/kb/318180
http://support.microsoft.com/kb/907434
http://support.microsoft.com/kb/301188
http://support.microsoft.com/kb/817433
http://support.microsoft.com/kb/306398
http://support.microsoft.com/kb/2028194
http://support.microsoft.com/kb/281271
http://support.microsoft.com/kb/319966