NOTE: I revised this article to fix some mistakes and to include new content from Windows Server 2008 R2.

Active Directory has built-in processes that exist to secure users that are members of privileged groups. These processes have been around for quite some time, but Active Directory administrators still get stumped by them regularly. What follows, is a updated look at AdminSDHolder, Protected Groups, and SDPROP. Windows Server 2008 R2 specific content has been added.

This article will provide you with the following information:

• Overview
• How AdminSDHolder Works
• Default ACL on the AdminSDHolder Object in Windows Server 2008 R2
• Default Protected Groups and Users
• Modifying How Often the AdminSDHolder Background Process Runs
• How to Determine if a User or Group is Protected by AdminSDHolder
• Orphaned AdminSDHolder Objects
• Security Descriptor Propagator
• How to Force AdminSDHolder to Run
• Additional Resources

Overview

Each Active Directory domain has an object called AdminSDHolder, which resides in the System partition. The AdminSDHolder object has a unique Access Control List (ACL), which is used to control the permissions of user accounts that are members of built-in privileged Active Directory groups (I will refer to these groups as protected groups moving forward). By default, a background process runs hourly on the domain controller that holds the PDC Emulator operations master role, which compares the ACL on all security principals (users, groups and computer accounts) that belong to protected groups against the ACL on the AdminSDHolder object. If the size or the binary string is different, the security descriptor on the object is overwritten by the security descriptor from the AdminSDHolder object.

The reason for all of this is to better secure user accounts that belong to protected groups. It accomplishes this better security in a few ways. First, the permissions that are applied onto users that belong to protected groups are more stringent than the default permissions that are applied onto other user accounts. Secondly, the default behaviour is that inheritance is disabled on these privileged accounts, which ensures that any permissions that are applied at the parent level are not inherited by the protected user accounts, regardless of where they reside. Lastly, the background process running every 60 minutes identifies manual modifications to an ACL and overwrites them so that the ACL matches the ACL on the AdminSDHolder object.

How AdminSDHolder Works

Let’s start by taking a closer look at how the AdminSDHolder process works. As previously mentioned, each Active Directory domain contains an AdminSDHolder object, which resides in the domain’s System container. The distinguished name of the AdminSDHolder object is "CN=AdminSDHolder,CN=System,DC=domain,DC=com," where DC=domain,DC=com is the distinguished name of the domain. The image below shows the AdminSDHolder object in a Windows Server 2008 domain.

Default ACL on the AdminSDHolder Object in Windows Server 2008 R2

The default ACL on the AdminSDHolder object is different than the default domain, OU, and container ACLs. Below is the default ACL on the AdminSDHolder object in a Windows Server 2008 R2 domain.

Owner: DOMAIN\Domain Admins
Group: DOMAIN\Domain Admins
Access LIST:
{This object is protected from inheriting permissions from the parent}
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS
   READ PERMISSONS
   LIST CONTENTS
   READ PROPERTY
   LIST OBJECT
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS
   READ PERMISSONS
   LIST CONTENTS
   READ PROPERTY
   LIST OBJECT
Allow DOMAIN\Domain Admins
   SPECIAL ACCESS
   READ PERMISSONS
   WRITE PERMISSIONS
   CHANGE OWNERSHIP
   CREATE CHILD
   DELETE CHILD
   LIST CONTENTS
   WRITE SELF
   WRITE PROPERTY
   READ PROPERTY
   LIST OBJECT
   CONTROL ACCESS
Allow DOMAIN\Enterprise Admins
   SPECIAL ACCESS
   READ PERMISSONS
   WRITE PERMISSIONS
   CHANGE OWNERSHIP
   CREATE CHILD
   DELETE CHILD
   LIST CONTENTS
   WRITE SELF
   WRITE PROPERTY
   READ PROPERTY
   LIST OBJECT
   CONTROL ACCESS
Allow BUILTIN\Administrators
   SPECIAL ACCESS
   DELETE
   READ PERMISSONS
   WRITE PERMISSIONS
   CHANGE OWNERSHIP
   CREATE CHILD
   DELETE CHILD
   LIST CONTENTS
   WRITE SELF
   WRITE PROPERTY
   READ PROPERTY
   LIST OBJECT
   CONTROL ACCESS
Allow NT AUTHORITY\Authenticated Users
   SPECIAL ACCESS
   READ PERMISSONS
   LIST CONTENTS
   READ PROPERTY
   LIST OBJECT
Allow NT AUTHORITY\SYSTEM
   FULL CONTROL
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Account Restrictions
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Account Restrictions
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Logon Information
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Logon Information
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Group Membership
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Group Membership
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for General Information
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for General Information
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Remote Access Information
   READ PROPERTY
Allow BUILTIN\Pre-Windows 2000 Compatible Access
   SPECIAL ACCESS for Remote Access Information
   READ PROPERTY
Allow DOMAIN\Cert Publishers
   SPECIAL ACCESS for userCertificate
   WRITE PROPERTY
   READ PROPERTY
Allow BUILTIN\Windows Authorization Access Group
   SPECIAL ACCESS for tokenGroupsGlobalAndUniversal
   READ PROPERTY
Allow BUILTIN\Terminal Server License Servers
   SPECIAL ACCESS for terminalServer
   WRITE PROPERTY
   READ PROPERTY
Allow BUILTIN\Terminal Server License Servers
   SPECIAL ACCESS for Terminal Server License Server
   WRITE PROPERTY
   READ PROPERTY
Allow NT AUTHORITY\SELF
   SPECIAL ACCESS for Private Information
   WRITE PROPERTY
   READ PROPERTY
   CONTROL ACCESS
Allow Everyone
   CHANGE Password
Allow NT AUTHORITY\SELF
   CHANGE Password
Permissions inherited to subobjects are:
Inherited to all subobjects
Allow NT AUTHORITY\SELF
   SPECIAL ACCESS for Private Information
   WRITE PROPERTY
   READ PROPERTY
   CONTROL ACCESS

There are a few key points regarding the default ACL for the AdminSDHolder:

• Because the AdminSDHolder object is used in the process to secure privileged accounts, the default ACL on the AdminSDHolder object is more stringent than the default ACL on other objects, such as the domain, OUs and containers.
• In the default ACL for AdminSDHolder, the default Owner is the Domain Admins group, which is fairly unusual. Most Active Directory objects have the Administrators group as the default Owner. That’s significant because an Owner can take control of an object and reset permissions.
• Another important design factor for the AdminSDHolder object is that inheritance is disabled by default, which ensures that no parent-level permissions are inherited.
• Finally, the Administrators, Domain Admins, Enterprise Admins, and Administrators groups are the groups that have the write permission to attributes on AdminSDHolder, which is more stringent than the default permissions applied to other Active Directory objects.

Default Protected Groups and Users

The list of protected groups has evolved since the inaugural release of Active Directory. The list consisted of four security groups in Windows 2000 Server RTM. In Windows 2000 Server SP4 and Windows Server 2003, several other groups were added, including the Administrator and Krbtgt accounts. In Windows Server 2003 with SP1 and later versions, Microsoft removed the Cert Publishers group from the default protected groups. In Windows Server 2008, Microsoft expanded this list to include the Read-Only Domain Controllers group. The list of protected groups hasn’t changed in the Release Candidate build of Windows Server 2008 R2.

Windows 2000 Server RTM Windows 2000 Server with SP1 Windows 2000 Server with SP2 Windows 2000 Server with SP3	Windows 2000 Server with SP4 Windows Server 2003 RTM	Windows Server 2003 with SP1 Windows Server 2003 with SP2	Windows Server 2008 RTM Windows Server 2008 R2
Administrators	Account Operators	Account Operators	Account Operators
Domain Admins	Administrator	Administrator	Administrator
Enterprise Admins	Administrators	Administrators	Administrators
Schema Admins	Backup Operators	Backup Operators	Backup Operators
	Cert Publishers	Domain Admins	Domain Admins
	Domain Admins	Domain Controllers	Domain Controllers
	Domain Controllers	Enterprise Admins	Enterprise Admins
	Enterprise Admins	Krbtgt	Krbtgt
	Krbtgt	Print Operators	Print Operators
	Print Operators	Replicator	Read-only Domain Controllers
	Replicator	Schema Admins	Replicator
	Schema Admins	Server Operators	Schema Admins
	Server Operators		Server Operators

Controlling the Groups that are Protected by AdminSDHolder

The ability to control groups that are protected by AdminSDHolder was introduced via a hotfix for the RTM versions of Windows 2000 Server and Windows Server 2003 and is included in the most recent service pack for Windows Server 2003 and in the RTM versions of Windows Server 2008 and Windows Server 2008 R2. With this functionality, you can remove the following groups from being protected by AdminSDHolder:

• Account Operators
• Server Operators
• Print Operators
• Backup Operators

This functionality is provided by modifying the dsHeuristic flag. DsHeuristic is a Unicode string in which each character contains a value for a single forest-wide setting. Character position 16 is interpreted as a hexadecimal value, where the left-most character is position 1. Therefore, the only valid values are "0" through "f". Each operator group has a specific bit as follows:

Bit	Group to Exclude	Binary Value	Hexadecimal Value
0	Account Operators	0001	1
1	Server Operators	0010	2
2	Print Operators	0100	4
3	Backup Operators	1000	8

This becomes even more complicated when you want to exclude more than one group from AdminSDHolder. Especially because you can have multiple combinations of exclusions, for example Account Operators and Server Operators, or Account Operators and Backup Operators.

To deal with this, you simply add the binary value of each group and then convert the result to a hexadecimal value. For example, to exclude the Print Operators and Backup Operators groups, take the binary value for the Print Operators group (0100) and add it to the binary value of the Backup Operators group (1000), which equates to 1100. You then convert the binary sum (1100) to the hexadecimal value (C).

To make this a little easier for you, the table below lists all possible combinations in binary and hexadecimal format.

Group(s) to Exclude	Binary Value	Hexadecimal Value
None (Default)	0000	0
Account Operators	0001	1
Server Operators	0010	2
Account Operators Server Operators	0001 + 0010 = 0011	3
Print Operators	0100	4
Account Operators Print Operators	0001 + 0100 = 0101	5
Server Operators Print Operators	0010 + 0100 = 0110	6
Account Operators Server Operators Print Operators	0001 + 0010 + 0100 = 0111	7
Backup Operators	1000	8
Account Operators Backup Operators	0001 + 1000 = 1001	9
Server Operators Backup Operators	0010 + 1000 = 1010	a
Account Operators Server Operators Backup Operators	0001 + 0010 + 1000 = 1011	b
Print Operators Backup Operators	0100 + 1000 = 1100	c
Account Operators Print Operators Backup Operators	0001 + 0100 + 1000 = 1101	d
Server Operators Print Operators Backup Operators	0010 + 0100 + 1000 = 1110	e
Account Operators Server Operators Print Operators Backup Operators	0001 + 0010 + 0100 + 1000 = 1111	f

After you have decided which group(s) you want to exclude, you are ready to modify the dsHeuristics attribute. The process to modify the dsHeuristics attribute is outlined the following Microsoft KB article: 817433.

Modifying How Often the AdminSDHolder Background Process Runs

If the default frequency of 60 minutes for the background AdminSDHolder process to run isn’t sufficient, you can change it by creating or modifying the AdminSDProtectFrequency entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters subkey.

If this key doesn’t exist, the default frequency (60 minutes) is used.

You can configure the frequency to anywhere between one minute and two hours. You must enter the number of seconds when creating or modifying the registry entry. The following command will configure SDPROP to run every 10 minutes (600 seconds):

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters /V AdminSDProtectFrequency /T REG_DWORD /F /D 600

Note, however, that modifying this subkey isn’t recommended because doing so can increase LSA (Local Security Authority) processing overhead.

Also note that the addition of this subkey does not take effect until LSA reinitializes. This means it won’t take effect until the DC is rebooted, or until you restart the NTDS service on a Windows Server 2008 or Windows Server 2008 R2 DC.

How to Determine if a User or Group is Protected by AdminSDHolder

As you can see, the default users and groups that are protected by AdminSDHolder is fairly large. One thing to keep in mind is that users are protected by AdminSDHolder if they have direct or transitive membership in a security OR distribution group. Distribution groups are included because a distribution group can be converted to a security group. So, let’s say a user belongs to a distribution list called Canada IT. The Canada IT DL is a member of the North American IT security group and the North American IT security group is a member of the Administrators group. Because the user’s transitive group membership includes the Administrators group (by virtue of group nesting) the user’s account is protected by AdminSDHolder.

A number of individuals use the whoami command-line tool with the /all switch to determine their group membership. It is important to note that the whoami /all switch DOES NOT report nested distribution groups. The whoami /all command only reports nested security groups, in addition to the groups you are a direct member of.

There is, however, an easy way to determine which users and groups are protected in your domain by AdminSDHolder. The adminCount attribute can be queried to determine if an object is protected by the AdminSDHolder object. These examples use PowerShell cmdlets that are included with the Active Directory Module for Windows PowerShell.

To find all user objects in a domain that are protected by AdminSDHolder, type:

Get-ADUser -LDAPFilter "(objectcategory=person)(samaccountname=*)(admincount=1)"

To find all groups in a domain that are protected by AdminSDHolder, type:

Get-ADGroup -LDAPFilter "(objectcategory=group)(admincount=1)"

Orphaned AdminSDHolder Objects

When a user is removed from a protected group, the adminCount attribute on that user account DOES NOT change; the value remains set at 1. Furthermore, the status of inheritance is not changed. As a result, the user account no longer receives its ACL from the AdminSDHolder object, but it also doesn’t inherit any permissions from parent objects, provided inheritance has not been enabled on the AdminSDHolder object. The common term for this issue is "orphaned AdminSDHolder objects." There is no built-in automated mechanism to fix inheritance on objects that no longer belong to protected groups; you must deal with orphaned AdminSDHolder objects manually. Microsoft has developed and made available a VB Script that will assist you in re-enabling inheritance on user accounts that were previously members of protected groups. To find the VB Script, go to Delegated permissions are not available and inheritance is automatically disabled.

Security Descriptor Propagator

In order to propagate the changes of inheritable ACEs to descendent objects, domain controllers runs a background task called the Security Descriptor Propagator Update task. This task is triggered by a modification to the security descriptor for an object or when an object is moved.

It is important to note that SDPROP is not responsible for AdminSDHolder protection.

How to Force AdminSDHolder to Run

You can also force AdminSDHolder to run in cases where you are testing changes or cannot wait for the configured interval. Prior to Windows Server 2008 R2, you use the FixUpInheritance rootDSE LDAP modify operation to kick off SDPROP. In Windows Server 2008 R2, Microsoft introduced a new rootDSE LDAP modify operation, called RunProtectAdminGroupsTask, which can also be used to kick off the AdminSDHolder background task.

Using FixUpInheritance to Force AdminSDHolder to Run

As previously mentioned, you can use the FixUpInheritance LDAP modify operation to kick off SDPROP. The FixUpInheritance rootDSE LDAP modify operation is supported Windows 2000 Server and above. To use the FixUpInheritance modify operation , perform the following tasks on the PDC Emulator:

1. Go to Start, click Run, type LDP.exe, and click OK.
2. On the Connection menu in the LDP console, click Connect.
3. On the Connect window, type the server name you want to connect to into to Server field, ensure 389 is listed in the Port field, and then click OK.
4. On the Connection menu, click Bind.
5. On the Bind window, select the Bind as currently logged on user option or select the Bind with credentials option. If you selected the latter, enter the credentials you want to bind with. Click OK.
6. On the Browse menu, select Modify.
7. On the Modify window, FixUpInheritance into the Attribute field, type Yes into the Value field, select the Add operation, and then click Enter.
8. The Modify window should look like this:                                                                                                       
9. Click Run.

The amount of time that this takes to complete depends on the size of your Active Directory environment. The larger the environment, and the more Security Descriptors that have changed, the longer it will take the process to run. You can monitor the DS Security Propagation Events counter in the NTDS Performance object to determine when this has completed, which will be indicated by a counter value of 0.

Using RunProtectAdminGroupsTask to Force AdminSDHolder to Run

As previously mentioned, Windows Server 2008 R2 includes a new rootDSE LDAP modify operation, called RunProtectAdminGroupsTask, which can be used to cause the DC to truly force AdminSDHolder to run. With RunProtectAdminGroupsTask the requester must have the "Run-Protect-Admin-Groups-Task" control access right on the domain root of the DC. This must be run on the PDC Emulator to have an effect. Effectively, your PDC Emulator must be running Windows Server 2008 R2 to run this LDAP modify operation.

The following is an LDIF sample that performs this operation:

dn:
changetype: modify
add: runProtectAdminGroupsTask
runProtectAdminGroupsTask: 1
-

You can also use LDP (focusing on the rootDSE) to use RunProtectAdminGroupsTask to cause the DC to run the AdminSDHolder protection operation. This can be achieved by using the following steps on the PDC Emulator:

1. Go to Start, click Run, type LDP.exe, and click OK.
2. On the Connection menu in the LDP console, click Connect.
3. On the Connect window, type the server name you want to connect to into to Server field, ensure 389 is listed in the Port field, and then click OK.
4. On the Connection menu, click Bind.
5. On the Bind window, select the Bind as currently logged on user option or select the Bind with credentials option. If you selected the latter, enter the credentials you want to bind with. Click OK.
6. On the Browse menu, select Modify.
7. On the Modify window, leave the DN field empty, type RunProtectAdminGroupsTask into the Attribute field, type 1 into the Value field, select the Add operation, and then click Enter.
8. Click Run.
9. Close the Modify window.

Additional Resources

• Ask the Directory Services Team – Five common questions about and AdminSDHolder and SDProp
• AdminSDHolder, Protected Groups and SDPROP
• Description and Update of the Active Directory AdminSDHolder Object
• Manually initializing the SD propagator thread to evaluate inherited permissions for objects in Active Directory
• Delegated permissions are not available and inheritance is automatically disabled
• rootDSE Modify Operations Open Specifications Document
• runProtectAdminGroupsTask Open Specifications Document
• AdminSDHolder Open Specifications Document
• LDAP modify operations

Conclusion

The AdminSDHolder is an important security feature in Active Directory. The AdminSDHolder, coupled with Protected Objects, and the Security Descriptor Propagator, help secure user accounts that contain elevated Active Directory permissions. The AdminSDHolder functionality has evolved from Windows 2000 Server to Windows Server 2008. During this evolution, Microsoft has expanded the number of objects that are secured by AdminSDHolder. Furthermore, Microsoft has introduced the capabilities to exclude operator groups from the AdminSDHolder protection and to control the frequency of when AdminSDHolder runs.

Most Active Directory administrators have in one way or another been introduced to AdminSDHolder, intentionally or unintentionally. I tried to give you a good understanding of what AdminSDHolder is, how it works, the cleanup that is required when you remove a user from a protected group, and some tweaks that you can use for AdminSDHolder. Hopefully this information will enable you to ensure you are not caught off guard by the AdminSDHolder functionality the next time you delegate or remove Active Directory permissions.