Active Directory Domain Services uses AdminSDHolder, protected groups and Security Descriptor propagator (SD propagator or SDPROP for short) to secure privileged users and groups from unintentional modification. This functionality was introduced in the inaugural release of Active Directory in Windows 2000 Server and it's fairly well known. However, virtually all IT administrators have been negatively impacted by this functionality, and that will to continue unless they fully understand how AdminSDHolder, protected groups and SDPROP work.

Each Active Directory domain has an object called AdminSDHolder, which resides in the System container of the domain. The AdminSDHolder object has a unique Access Control List (ACL), which is used to control the permissions of security principals that are members of built-in privileged Active Directory groups (what I like to call "protected" groups). Every hour, a background process runs on the domain controller that holds the PDC Emulator operations master role. It 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..

As you can see, multiple layers of security are incorporated into this functionality. First, the permissions applied to users belonging to protected groups are more stringent than the default permissions applied onto other user accounts. Next, the default behaviour is that inheritance is disabled on these privileged accounts, ensuring that permissions applied at the parent level aren't inherited by the protected objects, regardless of where they reside. Finally, 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.

See the sidebar "A Common Example of the Impact of AdminSDHolder, Protected Groups, and SDPROP" for a real-world look at this functionality.

As mentioned, each Active Directory domain contains an AdminSDHolder object that resides in the domain's System partition. 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. Figure 1 shows the AdminSDHolder object in a Windows Server 2008 R2 domain.

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 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 and Enterprise Admins 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.

As previously noted, AdminSDHolder permissions apply to security principals that belong to protected groups. The list of protected groups has expanded since the inaugural release of Active Directory in Windows 2000 Server. Figure 2 shows the default protected groups and users from Windows 2000 Server to Windows Server 2008 R2.

The list of protected groups 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.

In my experience, a subset of these default protected groups causes problems with AdminSDHolder. For example, many organizations use the Print Operators group for Print Services management but not for Active Directory management. However, the Print Operators group is a protected group because it has elevated permissions on domain controllers by default. A best practice is to remove the elevated permissions that this group has on domain controllers. If you do follow this best practice (and you should!), you probably won't need to protect this group with AdminSDHolder.

You can exclude a subset of the default protect groups from the AdminSDHolder process, including:

This ability to control groups that are protected by AdminSDHolder was introduced via 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. For more information on the hotfix, go to Delegated permissions are not available and inheritance is automatically disabled.

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 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 shown in Figure 3.

This situation becomes even more complicated when you're trying 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 issue, 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 equals 1100. You then convert the binary sum (1100) to the hexadecimal value (C).

To make this task a little easier, Figure 4 lists all possible combinations in binary and hexadecimal format.

After deciding which group(s) you want to exclude, you're ready to modify the dsHeuristics attribute. For details on that process, see the sidebar "How to Use the dsHeuristics Attribute to Exclude Groups from AdminSDHolder."

A fairly large number of default users and groups are protected by AdminSDHolder. 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.

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; 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.

There's an easy way to determine which users and groups AdminSDHolder protects in your domain. You can query the adminCount attribute to determine whether an object is protected by the AdminSDHolder object. The following examples use the ADFind.exe tool, which can be downloaded from joeware.net.

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

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

Note: In the preceding examples, replace DC=domain,DC=com with the distinguished name of your domain.

When a user is removed from a protected group, the adminCount attribute on that user account does not change; the value 1 remains. 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 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.

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.

You can also force SDPROP to run in cases where you're testing changes or you can't wait for the configured interval. Forcing SDPROP to run involves manually initializing the SDPROP thread to evaluate inherited permissions for objects in Active Directory. This process can be achieved by taking the following:

At this point, SDPROP should initialize. The amount of time the SDPROP process takes depends on the size of your Active Directory environment. The larger the environment, 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 SDPROP has completed, which will be indicated by a counter value of 0.

The AdminSDHolder is an important security feature in Active Directory. The AdminSDHolder, protected groups and 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, introduced the ability to exclude certain groups from the AdminSDHolder and added the ability to control how often AdminSDHolder runs.

Most Active Directory administrators have been introduced to AdminSDHolder, intentionally or unintentionally. I've tried to provide you with a good understanding of what AdminSDHolder is, how it works and what cleanup is required when you remove a user from a protected group, along with some useful tweaks. I hope that this information will help prevent you from being caught off guard by the AdminSDHolder functionality the next time you delegate or remove Active Directory permissions.