This is the overview of the situation. I just took over AD in an environment that is a 24/7 production environment with little to no ability to be taken down. The previous administrators did a lot of really poorly thought out band-aiding of issues and now I am trying to fix it while not bringing the environment down and allowing us the ability to test the effects before making any major changes.
The first issue on the agenda is that for some reason someone put the Domain Users group into the Builtin\Administrators group which allows all users unadulterated access to servers and who knows what else. Not knowing for certain what will happen when I take the Domain Users out of Builtin\Administrators I wanted to hedge my bets by creating a new group (All Users) and having the same members in it as in Domain Users. The plan was to put the All Users group into the Builtin\Administrators group, allow it to trickle down, and then remove Domain Users, hopefully allowing everyone to maintain the same rights while allowing new users (especially for testing) to have the proper rights and allowing us to confirm what needs to be done before fully removing the admin rights for everyone.
The major problem. When I add the All Users to the Builtin\Administrators group the next morning the Builtin\Administrators group is reset and All Users is no longer there. As it is best case scenario is that if I added the All Users in and took the Domain Users out tomorrow it would be as if nothing had happened, worst case is that All Users is removed and Domain Users isn't restored leaving us with a completely untested environment.
What has been done and found so far. While looking for the why this is happening I found out more about the AdminSDHolder and the various processes around it. I have confirmed that for the SDProp process it is not set off of the default time so every hour it should run, however the issue is that I've watched the group over the course of about 6 hours and All Users stayed where it was put the entire time. I however do not know if the runProtectAdminsGroupTask runs at the same hour interval (In which case something else is making the chage) or if it is run once a day (In which case it may be the cause for this issue). I have made changes to the dsHeuristics setting to set it to f where it maximizes what is excluded and I have used ADSIedit to go into the attributes for Builtin\Administrators to set adminCount to 0. When I go into LDP and connect to the server to kick off the fixupInheritance or the runProtectAdminsGroupTask I get the same error.
ldap_modify_s(ld, '(null)',[0] attrs);
Error: Modify: Unwilling To Perform. <53>
Server error: 00000057: LdapErr: DSID-0C0422CE, comment: Error in attribute conversion operation, data 0, v23f0
Error 0x57 The parameter is incorrect.
I have confirmed I do have the correct rights to run the command.
Another issue I have found which is likely very much related and may be an contributing factor is that utilizing a tool called LIZA I have run a search on everything with blocked inheritance and found that because of the groupings and such every single user in the environment has inheritance blocked and is likely "protected" with AdminSDHolder.
So in the end the simple act of adding the All Users group to the Builtin\Administrators group is running into walls and I was hoping someone could show me how to get around them. Trying to Audit the changes on the Builtin\Administrators group failed because since the group is reset all of the audit settings are reset too with no events being logged. Errors prevent me from kicking of suspected processes causing the issue for me to be able to confirm if my solutions are working, forcing me to way at least a day inbetween potential fixes. And all the while even a brand new and clean user can log into any of our servers and cause havoc. I am need of help please.
Edit: I was able to find the issue with trying to manually kick off the AdminSDHolder check. I'm unsure it worked but I am making progress in this quest to undo the mistakes of admins past.