Forum Discussion

Parzival30's avatar
Parzival30
Copper Contributor
Aug 20, 2021

ACLs on privileged groups

Hi everyone, We are trying to clean up the security ACLs on a few privileged groups. My biggest issue right now is when I select disable inheritance and remove all of the groups/users off the main gr...
Active Directory
LainRobertson's avatar
LainRobertson
Silver Contributor
Nov 10, 2021

Parzival30 

 

I'm going to wager the author's moved on, but I'll answer this anyway.

 

  1. Yes, this is a direct result of the SDProp process. You can read more about the process and the identities it protects here;
  2. To effect a change on the applied ACL, you have to modify the "master" ACL on the AdminSDHolder object within Active Directory, which is located under "CN=AdminSDHolder,CN=System,DC=yourDomain,DC=com";
  3. The adminCount attribute does not control anything, and is only a semi-reliable indicator as to who is protected.

Note: I ordinarily recommend you do not change the ACL on AdminSDHolder.

 

If you do change the ACL, you don't get to choose which subset of groups and accounts it is applied to. Everything protected by the SDProp process will receive the same ACL which may lead to other unexpected outcomes.

 

SDProp sets adminCount to 1 when an object is added to a protected group, however, it is not subsequently reset to 0 if the object is subsequently removed. Hence, why I say it's only a semi-reliable indicator.

 

Additionally, if you're playing around with the AdminSDHolder ACL, keep in mind that the ACLs on affected objects have inheritance disabled, and just as with the adminCount attribute are not reset if the object falls out of scope of the SDProp process. You will have to identify such objects and re-enable inheritance yourself.

 

This can be scripted via PowerShell (or whatever language you prefer) but, frankly, as I said above, I'd just leave it alone unless you have a profoundly compelling reason for fiddling with it.