Non admin accounts keep losing their delegated rights to admin accounts (part 1)

Here’s something that I learnt the other day.

At work we use a bunch of admin accounts for various tasks. Previously all these admin accounts were part of the Domain Admins group, but recently in a drive to tighten down things we removed many of these accounts the from Domain Admins group. These accounts are still members of the other built in groups such as Account Operators and/ or Server Operators though, but not Domain Admins.

After removal we noticed that the accounts that were not Domain Admins could no longer reset passwords or unlock accounts for any admin accounts. Not surprising – since the Domain Admins group is what has such rights on all accounts once these users are removed from the Domain Admins group they naturally lost their rights. This needed fixing so here’s what we did: all our admin accounts (both Domain Admins and others) were in an OU called “Admin Accounts”, so we put the accounts that were not in the Domain Admins group into a group called Limited Admins and delegated this group rights to reset passwords on the “Admin Accounts” OU.

delegate

rights

Notice the Limited Admins group has a reset password Access Control Entry (ACE) on the “Admin Accounts” OU. This is a result of the delegation. If I check an individual account in this OU, the ACE entry is present on it too.

rights2

Once this was done and dusted a funny thing happened. Initially the Local Admin groups members could reset everyone’s passwords but soon they complained they were unable to. We checked the OU and an example Domain Admin account and noticed the previous ACE was no longer present. The ACE was still present on the OU and on accounts that were not members of the Domain Admins group, but it was missing from accounts that were members of the Domain Admins group or even groups such as Account Operators and Server Operators. Very odd!

We checked whether any of the other admins were removing these rights intentionally but none were. Next we checked the Event Viewer but that didn’t have anything to add. Finally we enabled auditing of account management activities to see if that sheds some light. An important point (which I had missed out initially) is that to view the extra details one must check the Event Viewer of the Domain Controller with the PDC Emulator role. To find out the DC with the PDC Emulator role open “AD Users and Computers”, right click on the domain name, select Operations Master:

pdcemul

Sure enough when we went through the Event Viewer of this DC there was an entry which explained what was happening:

event 4780

Interesting! At least this explains what was happening. And now that we knew what was happening the next step was to read more about the AdminSDHolder object and tweak things so our accounts didn’t get their ACEs stripped. This post took longer than expected to type up, so more on that in my next post …