So now you know why your delegated permissions are disappearing on a regular basis. So now you know that you were not imagining things or hallucinating. So, what are you going to do about it?
You have 2 options:
1. Live with it and don’t delegate things to any account that belongs in any of the “protected” groups – yeah right :)
2. Do what a typical admin would do and find a “work-around” because, face it, delegation of tasks/permissions is a way of life in any AD environment. If you are not utilizing delegations, there is a high degree of probability that you are granting TOO MUCH permissions to someone.
So, the focus of this thread is to recap how to work around the constraints of AdminSDHolder.
The first task in tackling the AdminSDHolder imbroglio is to be able to identify the groups that are, by default, protected. We did this in the previous email.
The next step is to be able to identify, at a glance, which account is currently affected by AdminSDHolder. Remember, you can not delegate to any account that is protected either directly or by virtue of it belonging in a “protected” group. EVERY account that is affected by AdminSDHolder ALWAYS has its “AdminCount” attribute set to “1”. So, to see which account is protected, all you need to do is look for accounts that have AdminCount=1.
The following command will output the affected accounts into a text file called “Protected_Acct.txt” in a domain called mydomain.myTLD:
ldifde -f protected_Acct.txt -d dc=mydomain,dc=myTLD -r "(&(objectcategory=person)(objectclass=user)(admincount=1))" -l admincount
The following command will output the affected groups into a text file called “Protected_Acct.txt” in a domain called mydomain.myTLD:
ldifde -f protected_Acct.txt -d dc=mydomain,dc=myTLD -r "(&(objectcategory=group)(objectclass=group)(admincount=1))" -l admincount
The following command will output both the groups and accounts into a text file called “Protected_Acct.txt” in a domain called mydomain.myTLD:
ldifde -f protected_Acct.txt -d dc=mydomain,dc=myTLD -r "(&(admincount=1))" -l admincount
OK, now that we have a list of all protected accounts/groups, a typical admin may want to be able to delegate permissions to a group or a user even though the group or user is “protected”. Here are your options:
1. Remove the user or group in question from the “protected” Group. This means that the user or group that you are delegating to should NOT be a member of ANY of the “Protected” groups you see in the output of the third command. After removing them, you then need to also reset the inheritance flag on the user/group so that delegated permissions will stick next time you apply it. Resetting the inheritance flag requires a script. Although this is the best and most effective method, the solution can be impractical for the following reasons –
a. Some of the “Protected Groups” are really must-have for a lot of environments, so users/groups from them may not be desirable. For example, you want someone to be a backup operator, but you still want to delegate account unlock permission to the person. With this option, you will run into a catch-22 scenario.
b. Secondly, even if you remove the person/group from the “protected” group, the AdminCount=1 is not automatically cleared, so it is still possible for the permission to still disappear even though the user/group is no longer in any “Protected” group. You will have to consciously and manually reset the AdminCount attribute to 0
c. The third problem is the need for script. If you are not a scripter, this can be involved.
OR
2. The second option is a variation of the first. Instead of removing users/groups from “Protected Groups” and changing their inheritance flags one at a time, if you just modify the AdminSDHolder container so that this container is able to allow inheritance, then this change will carry over to ALL “Protected Groups”, and, from there, to any user/group that belong to these “Protected Groups”. What this means is that now, when you apply delegated permissions to any of the affected users/groups, the permission will not disappear because ACL on the AdminSDHolder container itself allows permission inheritance. The problem with this is that you have now effectively defeated the purpose and usefulness of AdminSDHolder. This means that less privileged admin can now apply undesirable permissions to the protected objects.
OR
3. The 3rd option is a middle ground between the first 2 options above. Instead of just crippling the AdminSDHolder feature by letting anyone manipulate its ACL through inheritance, you can just selectively adjust the ACL the AdminSDHolder container (CN=AdminSDHolder,CN=System,DC=myDomain,DC=myTLD) to fit your need. Say, for example, you want your helpdesk folks (who reside in, say, “Accounts Operators” group) to be able to manipulate the properties of people in the “Protected Groups” (for example, change the password or unlock accounts of a Domain Admin member), you will just edit the Security (through the GUI) properties of (CN=AdminSDHolder,CN=System,DC=myDomain,DC=myTLD) and add the “Accounts Operators” group to the permission list and select the applicable permission.
To be sure, the degree to which you can set ACL on objects through the GUI depends on a number of factors. These will have to be addressed in future discussions. In the meantime, see the following for hints:
http://support.microsoft.com/?kbid=296490
OK, I admit. The above will take at least 2 readings to digest. The best way to grasp the work-around is to fire up some DCs in your virtual environment and go through the steps.