I ran into a strange one recently. I have been trying to delegate some permissions to people to manage objects in AD. For *some* but not all, after I’d make the change, the ACL’s were reverting back. Sometimes in a few minutes and sometimes nearly an hour later. I thought I had a replication issue but… no other issues were present and nothing else was reverting back. I was pounding my head against the wall (as usual, because it is so helpful) and there was an alarm ringing in the back of my head, “Chris, you’ve heard of this before” but it finally just clicked yesterday.
Turns out that a whole handful of users in my org belonged to the “Server Operators” built-in security group. This is a protected group, as are:
I wasn’t aware that Server Operators was now protected (initially they weren’t), but I guess that happened in 2000 SP4. Oops, missed that on an MCSE test exam question somewhere along the line I’m sure.
Anyway, here’s what is happening. A protected group gets its ACL’s reset back automatically (if they’ve changed) once per hour. The template for this reset is called AdminSDHolder and is located at CN=AdminSDHolder,CN=System,DC=mydomain,DC=com.
So if, for instance, you change the ACL’s on somebody’s user account and give some other group the ability to reset the password for that object… one hour later that permission will disappear and the group won’t have access to reset the password. But only if that user account you tried to change is a member of one of the protected groups above.
The PDC Emulator runs this job once every 60 minutes. So after making the change, you won’t even notice that the problem for up to an hour. If fact, you’ll think you finished the task.
To make things worse, the box for inheriting permissions will uncheck as well – meaning if you tried to delegate a whole OU it will work for some accounts and not for others.
So… how to fix it? For me I just yanked them out of the Server Operators group and that fixed it. But if you need to keep the security group mentioned above, you have two options. Modify AdminSDHolder with new permissions or take the group in question out from under the protection of AdminSDHolder. Ned (as usual) has a good article about these options here so no need to go into them and re-invent the wheel.