Skip navigation

Q. How can I force AdminSDHolder permissions to be enforced?

Q. I made some changes to the Active Directory (AD) permissions in our test AD forest and I'd like to check whether these changes are compatible with the permissions Windows enforces using the AdminSDholder mechanism. AdminSDHolder is a built-in AD mechanism that Microsoft provides to protect against the unauthorized modification of permissions on critical security groups and accounts, such as the Enterprise Admins, Schema Admins, and Domain Admins groups. At regular intervals, AdminSDHolder resets these groups and accounts’ access control lists (ACLS) to a set of predefined permissions. Instead of waiting for the automatic application of the AdminSDHolder permissions, which happens automatically every hour—I'd like to force the application of the AdminSDHolder permissions. How can I do this? 

 A. Microsoft provides two mechanisms to force AdminSDHolder to run. Prior to Windows Server 2008 R2, you had to use the FixUpInheritance rootDSE LDAP modify operation on your AD. The FixUpInheritance rootDSE LDAP modify operation can be used on all Windows AD versions. In Windows Server 2008 R2, Microsoft introduced a new rootDSE LDAP modify operation, called RunProtectAdminGroupsTask, to start the AdminSDHolder process.

 The new Windows 2008 R2 RunProtectAdminGroupsTask-based mechanism provides a more efficient mechanism to enforce AdminSDHolder application. Under the hood, the older FixUpInheritance-based mechanism doesn't really kick off the AdminSDHolder process—it starts the Security Descriptor Propagator Update (SDProp) process. SDProp has the same effect on the ACLs of critical security groups and accounts but takes much longer to complete. SDProp is the background AD process that propagates changes of inheritable ACEs on parent objects to their child objects. It's automatically triggered when an object’s ACL is modified or when an object is moved. SDProp affects all AD child objects’ ACLs and not only the ACLs of critical AD security groups and accounts and will thus consume much more DC processing time.

To use the FixUpInheritance rootDSE modify operation you must perform the following tasks on the DC that hosts the PDC Emulator Operations Master role:

  1. Start LDP.exe.
  2. Select Connect from the LDP Connection menu.
  3. In the Connect window, type the DC name in the Server field, ensure 389 is listed in the Port field, and click OK.
  4. Select Bind from the LDP Connection menu.
  5. In the Bind window, select the Bind as currently logged on user option or select the Bind with credentials option. In the latter case you must enter the credentials you want to bind with. Click OK.
  6. Select Modify from the LDP Browse menu.
  7. In the Modify window, type FixUpInheritance into the Attribute field, Yes in the Value field, select the Add operation, and click Enter.
  8. Click Run

To be allowed to make this change, your account must have the Recalculate-Security-Inheritance control access right on the NTDSDSA object of the DC.

To use the newer RunProtectAdminGroupsTask-based mechanism in Windows Server 2008 R2 you can use the same steps as above except for step 7, which should now be:

 

7. In 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.

 

To be allowed to make this change on Windows Server 2008 R2 your account must have the "Run-Protect-Admin-Groups-Task" control access right on the domain root of the DC.

TAGS: Security
Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish