Understanding Privileged Accounts and the AdminSDHolder

The information below will help you understand the adminSDHolder rule, which resets the security permissions on privileged accounts every 60 minutes.

The concept of delegation on AD objects is known to all AD administrators. The need to create custom delegation on objects is common; and even though AD delegation can be quite complex, the amount of experience and knowledge that has been shared, has simplified the process.

Here is the known problem: Imagine you delegate permissions to an OU but for some reason certain objects do not take the new ACL (Access Control List). You perform the delegation again, and confirm that the ACL is on the object correctly. You go about your business and after a while realize that the custom delegation is not working. You go back to check the object and your custom delegation is gone. What happened to my custom delegation?

Active Directory and Protected Groups

Ever since Windows 2000, Active Directory has had a mechanism to ensure members of protected groups have standardized and controlled security descriptors. The process is complex and there are many moving parts that are worth exploring and defining. In the end, excluding certain protected groups from this process may be quite helpful.

There is much information on TechNet and MSDN that explores these concepts and a simple Google search will uncover additional information.

Let’s explore some of the parts and provide some context.


AdminSDHolder is a container in AD that holds the Security Descriptor applied to members of protected groups. The ACL can be viewed on the AdminSDHolder object itself. Open Active Directory Users and Computers and ensure Advanced Features is selected in the View menu. Navigate to the ‘system’ container under the domain and right-click on the sub-container called AdminSDHolder and select properties. The Security tab displays the ACL that will be applied to all members of protected groups.

Alt text for this image

SD Propagator

The SD Propagator is a process that runs on a schedule on the PDC emulator to find members of protected groups and ensure the appropriate Access Control List (ACL) is present. The SD Propagator runs every hour by default but can run at a different frequency by adding the value AdminSDProtectFrequency to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. This can be configured anywhere between one minute and two hours. If the value is not present in this registry sub key, the default of 60 minutes is applied.


The dsHuerisitcs attribute is a Unicode String value on the Directory Service object in the configuration container. It defines multiple forest wide configuration settings, one of which being built-in groups to be excluded from the list of Protected Groups. You can view the value of the dsHuristics attribute in the LDP or ADSIEdit tools. Below is the attribute viewed from ADSIEdit.

Alt text for this image

If a built-in group, from the table below, needs to be excluded from the protection of the SD Propagator, this value will need to be updated. It must be done carefully as it is a forest wide setting and the value has implications across other pieces of configuration. You can Google this to find explicit instructions on how to update this attribute. Below are the groups that can be excluded from the process and the values that they carry. If multiple groups are to be excluded, their values are added together.

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


The adminCount attribute is found on user objects in Active Directory. This is a very simple attribute. If the value is <not set> or 0 then the user is not protected by the SD Propagation. If the value of adminCount is set to 1 that means the user has, or has been a member of a protected group. The value can be seen in ADUC or ADSIEdit or LDP. Below is the attribute viewed via ADUC.

Alt text for this image

What does this mean for Specops Users?

Well for most, nothing. But for some Specops Password Reset (SPR) users, there may be some tasks that need to be executed. The reason being for each user managed with SPR, the enrollment data must be stored as extension attributes to the individual user objects in AD. This requires the Service Account used by SPR to have rights over the user objects in the scope of management of SPR. The ability for the Service Account to perform this task is managed by permissions. Essentially SD Propagator will run every hour, find the users who are or were members of Protected Groups (users with adminCount set to 1), and apply the ACL from AdminSDHolder onto those objects.

So there are a few things to keep in mind, you can either choose to simply not let members of protected groups participate in the self-service management of their passwords or you can perform one of the processes to allow members of protected groups to be included. In the end, the user object will need to have an ACL that allows the SPR service account to perform its tasks.

Alt text for this image

For more information on how to identify and fix affected accounts, see: https://specopssoft.com/blog/troubleshooting-user-account-permissions-adminsdholder/

Recommended Readings

Make sure to search MSDN, Technet, and other web resources to find instructions and guidance on how to manipulate these attributes. Here are a few articles to get you started: