AdminSDHolder – Delegate administration of admin accounts?

Every now and then, the user administration staff (UA) has to administer groups for which domain admin rights are required. However, “admin accounts” of the UA usually don’t have these permissions. This leads to the following questions:

• What happens if UA admins assign permission, without having domain admin permissions? or
• Why can’t the helpdesk reset passwords of former admins?

Basics and Delegation Problem

For a better understanding of this problem, this article starts by describing the concept of users and administrators. Then, particularities like the difference between a domain admin and a “processing” helpdesk admin are explained. Lastly, I want to explain the behavior of Active Directory:

What happens when delegates administer accounts or groups, which they don’t have sufficient rights for?

Users and Administrators

Microsoft differentiates between user and administrator in Active Directory and recommends to never give admin permissions to users who work on a daily base with their accounts (e.g. Outlook or other applications). Administrative processes in the AD should always be carried out from a special, personalized admin account.

It is not advisable to give domain admin permissions to every user who occasionally administers something. These rights are too extensive for most users and make the auditing process more difficult. What is most important, is that someone can knowingly or not-knowingly cause great damage with an account like that.  

Delegation possible? Administration of High Privileged Users

To set up new users or reset passwords, you don’t need domain admin permissions. In these cases a delegation of the tasks is possible and makes sense.

But this is different for High Privileged groups and users. To administer these objects domain admin permissions are needed. High Privileged are all those users and groups which are allowed to administrate the Active Directory:

High Privileged groups:

• Administrators
• Account Operators
• Server Operators
• Print Operators
• Backup Operators
• Domain Admins
• Schema Admins
• Enterprise Admins
• Cert Publishers

High Privileged user accounts:

• Administrator
• Krbtgt

In the Microsoft world, members of these groups need special protecting (direct and indirect members).  This is where the AdminSDHolder comes into play.

If you want delegates to administer High Privileged users and their groups, access to them is prevented by the AdminSDHolder. However, this does not happen immediately. User accounts that are allowed to change permissions for these accounts can actually proceed them, but only in a limited time frame. 

Admin Security Descriptor Holder – AdminSDHolder

What does the AdminSDHolder do specifically? First, it checks whether the user account is a member of one of the protected groups. There is a registry key to determine the inspection intervals:

• Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
• Key: “AdminSDProtectFrequency” als REG_DWORD (without quotation marks)
• Value in seconds: 60 to 7200

The default value is 3600 seconds (60 minutes) but can be changed on the PDC-emulator of the domain. It shouldn’t be set too low though, as that could lead to performance issues.

If the user is a member of a protected group, the value of the attribute AdminCount is changed:

A value of 0 indicates the user not being a member of the above mentioned group.
A value of 1 indicates the ADminSDHolder being active and doing its work for that account.

As the AdminCount value cannot be viewed in the “Users and Computers Console”, I reccommend using ADSI Edit.

Authorizing High Privileged groups or users on an account with AdminCount “1”, enables them to edit it in the future.  

But what if an AD object is not High Privileged itself? If it is authorized on an account with ADminCount “1”, it will be displayed in its ACL as well – at least initially. In this case, the user account can also be edited. But only until the next cycle of the AdminSDHolder. After one hour (with the default value of 3600) at the latest, the ACL of the AdminCount “1”-user is cleared.

Furthermore, the inheritance for the account is interrupted. If the account is located in a delegated OU, the delegated permissions are invalid for it.

Editing Former Domain-Admin-Accounts is not Possible

I want to explain this a bit more into detail with the help of a little example:

A helpdesk employee (not member of a High Privileged group) is authorized to reset passwords for a specific OU. Because of in-house changes, the account of a former domain admin is located in this OU, too. This user account still has an AdminCount of “1”. Thus, the helpdesk employee cannot reset the password despite havign the permission to do so on that OU.

Further Effects/ Resetting AdminCount

Has the user previously been a member of a group protected by AdminSDHolder, its AdminCount is still „1“. The value is not automatically reset to “0”. That is how former admin users can be protected by AdminSDHolder after a restructuring of the AD.

For that special case, Microsoft provides a script which resets all AdminCounts to “0” and reactivates the inheritance. During its next cycle, AdminSDHolder then sets the AdminCounts of all accounts still in a protected group back to “1”. Like this, you can get rid of old burdens and prevent a security gap.

To make all that comprehensible, an Eventlog-entry with the ID 4780 is created.

Circumvent AdminSDHolder

Hence, a delegation for admin accounts is not that simple. There are actually ways to work-around AdminSDHolder, but I strongly discourage it. It is a grave intervention in the Active Directory and can cause major damage. That is why I will not explain it further in this post.