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

Previously I had stopped with an Event Log entry introducing the AdminSDHolder object.

Here’s the message from the Event Log entry:

Every hour, the Windows domain controller that holds the primary domain controller (PDC) Flexible Single Master Operation (FSMO) role compares the ACL on all security principal accounts (users, groups, and machine accounts) present for its domain in Active Directory and that are in administrative groups against the ACL on the AdminSDHolder object. If the ACL on the principal account differs from the ACL on the AdminSDHolder object, then the ACL on the principal account is reset to match the ACL on the AdminSDHolder object and this event is generated.

Turns out Active Directory protects its administrative groups by checking their Access Control Entries (ACEs) every hour against the ACE of the AdminSDHolder object. If the ACEs don’t match then the ACE of the administrative group is replaced with the ACE of the AdminSDHolder object. Not only that, every object that’s a member of these administrative groups too has its ACE compared with the AdminSDHolder object and if these ACEs don’t match they too are replaced!

This’s a pretty good security feature actually – this way no one can hijack admin accounts. Imagine you are a nice domain admin while I am a lowly evil admin who happens to have the right to reset everyone’s passwords. Maybe I wasn’t intended to have this right – I was assigned this right to all user accounts in the domain and via inheritance your domain admin account too had the right applied. Since I am a evil admin I can wait for you to go on holidays, reset your password, login as you and make any changes in your name. When you return from holidays your password won’t work but you’ll think that’s because you forgot your password while on holiday rather than anyone resetting it inappropriately. So you’ll get someone to reset it and carry on as usual; meanwhile I have got away with what I did.

Now imagine the same scenario but with the AdminSDHolder check active. What will happen now is that I will get reset passwords rights to your domain admin account, but in less than 60 mins AD will notice that the additional ACE does not match the ACE on the AdminSDHolder object and so remove it. Your account is thus safe and I can’t do anything naughty with it!

So what is the AdminSDHolder object? It is an object in the System container of the domain. It doesn’t have any objects within it but if you right click and check the Security tab you can view the various ACEs applied to it. These are the ACEs that will be applied to each administrative group, user, and machine in this domain.


The permissions on the AdminSDHolder are quite limited and more importantly inheritance is disabled so it doesn’t inherit permissions from elsewhere. Also the owner of this object is set to the Domain Admins group. This is important as the owner of an object can reset permissions.

The list of administrative groups that the AdminSDHolder object protects various with each version of Windows Server. Below is a list from Microsoft’s page.

admin groups

Worth noting that you could be in the “Print Operators” group too and that’s enough to protect your account! Turns out that’s because the “Print Operators” group has elevated permissions on domain controllers. It is possible to exclude the “Print Operators”, “Account Operators”, “Server Operators”, or “Backup Operators” groups from being a protected group. For that you need to DS-Heuristics attribute. This is a forest-wide attribute. The 16th character of this attribute controls the groups that are excluded from the AdminSDHolder protection. This page from Microsoft shows how you can exclude the groups.