Regarding AdminSdHolder
Windows 2000 and 2003 both contain protected groups, called AdminSdHolder. AdminSdHolder is used to control the permissions of user accounts that are members of the built-in Administrators or Domain Administrators groups. Protected Groups are groups that Windows protects from unnecessary changes. In some instances, this process can confuse people, even causing some unexpected behaviors when delegating administrations. However, this is actually a design feature for better security control. This article will explain the roles of protected groups and how the AdminSDHolder object is used in conjunction with protected groups.
Have you met with the following wired behavior?
1. Make a change to a user ACE (Access Control Entry) for an OU and find out that, for some reason, there is an account that the ACL doesn’t get applied to a particular user.
2. Explicitly configure the Send As right on a user object in the Active Directory Users and Computers snap-in in Microsoft Exchange Server, however, the Send As right is removed from the user object in about one hour.
3.Delegated permissions are not available to all users in an organizational unit.
4.Inheritance is automatically disabled on some user accounts, approximately once an hour
5. Users who previously had delegated permissions no longer have them.
More than likely, this is due to a special container called AdminSDHolder. Active Directory protects certain accounts not to inherit delegated permission. This behavior applies to direct and nested members of the following security-groups:
Windows 2000 SP3:
Enterprise Admins
Schema Admins
Domain Admins
Administrators
Windows 2000 SP4 and Windows Server 2003 additional:
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers
Let's look more into AdminSDHolder and see what exactly it does.
What AdminSDHolder does:
All objects in Active Directory have an ACL. The basic function of AdminSDHolder is exactly what it says it does - it holds the Access Control List (ACL) for every admin account. This container is just a template.
In order to protect highly-privileged accounts, the DC that holds the PDC Emulator role goes through every account that is in built-in Administrators group and checks the ACL for each user object once every hour. There is an AdminSDHolder object whose ACL serves as a template for ACLs on protected objects. It compares this ACL to the template of the AdminSDHolder container and if any Access Control Entry (ACE) is different, it rips out the old ACL and copies the ACL from the AdminSDHolder over to it. AdminSdHolder also applies the permissions to accounts which are nested members through distribution groups since the distribution group could be converted to a security group.
During the enforcement process, the PDC Emulator removes the "Allow Inheritable Permission from Parent" check box. If the user object is ever removed from the built-in Administrators group (or any groups nested in the Adminstrators group for that matter), the inheritable permissions flag remains turned off. Because of this, those accounts will not inherit new ACEs. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users.
Why is the AdminSDHolder object needed?
The purpose of AdminSDHolder is to prevent a specific attack scenario. All objects including OUs in Active Directory have an ACL. With delegation or assigning appropriate permissions to a user, the user can have write access to anything inside of a specific OU. These ACLs can also be changed by anyone with permissions to do so. By default, only administrators have the necessary permissions to do this; however, Active Directory was designed to be scalable, to be used in large, disparate environments and to support many delegation scenarios. When you delegate control to users and/ or groups (essentially, set permissions on objects for these users and/ or groups) you increase the likelihood of giving non-administrative users permissions to modify attributes, permissions, etc. on administrative accounts.
For example, think of a scenario in which a group is delegated control over an OU and in that OU resides several members of the domain admins group. Depending on the permissions defined on the OU, this group that have had permissions delegated to it could be able to change the members of the domain admins group.
Considering another scenario, if an admin account is moved to an OU that a non-admin has rights to, he could give himself privileged access to the admin account. It would be a grave security hole if any user with permissions to change group memberships on all user objects in an OU were to be able to modify the administrative users. With AdminSDHolder existing, the system tries to prevent this from happening by continuously refreshing the ACL on an admin account.
What can we do if encountering issues related to AdminSDHolder?
A benefit of AdminSDHolder is how you can use it to modify the ACLs of privileged accounts. This comes in handy when you want to do something such as give only a particular group the ability to reset passwords on admin accounts. You would just add the "Reset Password" ACE to ACL of the AdminSDHolder container and the ACL change would be populated during the next refresh cycle. Although it’s possible to correct issues by modifying the ACL on the AdminSDHolder object itself, that procedure is usually not advisable, as any mistake could quickly be propagated to the protected objects. In addition, when the ACL is viewed using the standard AD Users and Computers MMC snap-in, only a subset of possible ACEs is available, because the AdminSDHolder object is a container (and therefore, certain group and user object ACEs are unavailable); to set more advanced permissions, one would need to script a solution or use the dsacls.exe utility.
As a resolution, you can remove certain less-secure groups from AdminSDHolder protection by installing the hotfix and following the instructions here:
Delegated permissions are not available and inheritance is automatically disabled
https://support.microsoft.com/?id=817433
You can also try other workarounds mentioned in above article. For more information on AdminSDHolder or delegation administration, view the following KB article or link:
AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts
https://support.microsoft.com/?id=306398
Additional recommendations for AD administration:
· Usually you should avoid using administrative accounts for the daily routine. Use a regular user-account, and just start administrative applications (such as Active Directory-Users and -Computers) with administrative credentials (via RunAs or Context-Menu, Open with…).
· Check the box to inherit permissions when removing those users out of the protected group manually, or use a script described in https://support.microsoft.com/?id=817433 to check your users.
Comments
- Anonymous
December 30, 2013
A couple of weeks ago I was working with a customer analyzing a number of user accounts affected by AdminSDHolder - Anonymous
December 31, 2013
Pingback from How to Modify Security Inheritance on Active Directory Objects using PowerShell // AdminSDHolder | MS Tech BLOG - Anonymous
December 31, 2013
Pingback from How to Modify Security Inheritance on Active Directory Objects using PowerShell // AdminSDHolder | MS Tech BLOG