06 Nov

Understanding AdminSDHolder and Protected Groups

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.

clip_image001

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:                                                                                                    AdminSDHolder_03   
  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

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.

    8 thoughts on “Understanding AdminSDHolder and Protected Groups

    1. Pingback: The things that are better left unspoken : Active Directory Visibility Modes

    2. Revision history: This was initially posted roughly one year ago and it is still the most viewed post on my blog. I leveraged the content in this post to author an article for TechNet Magazine’s September 2009 issue (http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx). Joe Richards took the time to review my TechNet Magazine article, and pointed out some mistakes I had made in it. This an updated version of my blog post, which has the mistakes corrected, and contains new content specific to Windows Server 2008 R2. The online version of the TechNet Magazine article will be fixed soon.

    3. HI, We have 2003 environment. With 2003 forest and domain functional level.

      Now there is a group say x , which is member of 9 other groups . The group X is protected group as admincount is 1 . out of 9 groups 2 groups are protected.
      Say A, B are also protected.
      Now what is best thing to do if i want to make X non protected so that i can add members to group and they Stay for more than hour :)

      • Groups are protected by virtue of being nested (directly or indirectly) into an already protected group. Effectively, the scenario you’re painting means that group X is either nested in a protected group (directly or indirectly) or was at one point and is now a lingering protected object (it’s not receiving it’s ACL from AdminSDHolder and likely not inheriting ACLs). If you don’t want group X or its members to be protected, then remove it from the protected group (if this can be done in your environment and has not already been done) and then fix the lingering protected object.

    4. Pingback: Understanding AdminSDHolder and Protected Groups « Awinish's Blog..

    5. When running “runProtectAdminGroupsTask” via LDP, you need to uncheck the Synchronous box. Not doing so will cause the command to be unrecognised.

    6. Pingback: Why Do I Keep Losing Inheritance and Permissions on certain Accounts?

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>