Active Directory: Why the protected account permissions cannot be changed? what is AdminSDHolder?


If try anyone of the things below on accounts that is member of Domain Admins or Account Operators or any other protected groups, you know it can’t be done.

  • Changing permissions (add/remove/modify perms in security tab of the account properties window)
  • Enabling Permission Inheritance (to activate a ActiveSync account on the Administrator’s device)
  • Low-level admins (Account Operators) try to modify high-level admin accounts (e.g, Domain Admins, Enterprise Admins)

If you do any one of those actions above, it will be reset in 60 minutes automatically. The third action will be denied right away. Why is that? it’s because to protect the protected accounts from hacked. This feature first introduced in Active Directory in Windows 2000 Server. Here is detailed explanation from Microsoft.

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.

For more information check HERE.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s