Why are they in there? One customer’s tale of reducing the membership of their Domain Admins Group.

  • Article

This week I was onsite with a customer performing a visit called the Risk and Health Assessment Program for Active Directory (ADRAP).   Within the ADRAP, we collect data on many aspects of their Active Directory environment and discuss a wide variety of topics.   One of the things that we look at is the membership of the various Built-In administrative groups which exist within an Active Directory domain.   One of the conversations which I nearly always am having with customers as we discuss their members of these groups are what sorts of strategies that they can leverage to reduce the number of members in groups such as Administrators and Domain Admins and being able to delegate the permissions that classes of users need when possible instead of placing them into groups which grant them more rights and privileges than they actually need to perform their functions.   This holds as true of accounts which are used by flesh-and-blood users as it is with Service Accounts.   We discuss that if accounts need to be part of the local group Administrators on a subset of machines, don’t place those accounts into Domain Admins, leverage Group Policy Preferences to add it to the local group Administrators and target the GPO to the desired subset of machines.   We discuss delegating specific rights within Active Directory as necessary, and a variety of other strategies that they can leverage in order for accounts to have the rights and privileges required for them to function without giving them additional rights or paths to escalation.   We will discuss the rights granted to the Default Built-In Groups and how and when those can and should be leveraged.

With this particular customer, they have a need for the users who work within their Network Operations Center (NOC) to be able to handle that front-line sorts of tasks of the end-users within the environment.   This includes tasks such as unlocking accounts, changing passwords, joining computers to the domain, etc.   One of the steps that they took to provide these users the rights that they needed was to leverage the built-in group Account Operators.   They also have a need for users in the NOC to be able to perform these same functions against their peers.   What they discovered was that while membership in Account Operators met their needs for being able to manage the general end-users, it did not, however, meet their need of being able to manage their peers.   They also recognized that they would have benefits if the NOC could unlock the accounts of Domain Admins when those users locked themselves out.   (As happens in many customers, they admittedly have more accounts in the Domain Admins group than they would prefer and some of these accounts are only periodically used and the users with those accounts do not always remember their password.)    Their solution to these shortcomings of the Account Operators group was one faced by many customers, and generally not considered an optimal solution; they added the accounts of the NOC Leads to the Domain Admins group.   Let’s put that another way, in order to be able to manage the accounts which they’d prefer to have not put into the Domain Admins group in the first place, they put more accounts into the Domain Admins group.   If this sounds familiar to you, it is likely because you’ve either seen or worked in an environment where this same decision was made, or know someone who has.  (No judgments from me about this sort of situation, I’ve worked in places with even worse reasoning for putting massive numbers of accounts into Domain Admins.)

We decided to break their two requirements into each part and look at them individually.  There is a common component to both aspects, but we addressed them as separate parts.

First we looked into why the people in their NOC were unable to manage their coworker’s accounts.   This is because these accounts had transitive membership into the built-in group Account Operators.   It was the membership in the Account Operators group which caused the SDProp process to run for these accounts and remove the inheritance which would have normally allowed Account Operators to manage user accounts.   But without the inheritance, they could not manage their peers and it was because of this that their NOC Leads were added into Domain Admins.   We discussed SDProp and AdminSDHolder and they decided that to meet their business need of having these accounts be able to manage each other when required, we would leverage the dsHeuristics attribute to exclude Account Operators from AdminSDHolder.   We leveraged KB 817433 as our guide and set dsHeuristics to a value of 0000000001000001.  This excluded the accounts from the SDProp thread setting their ACE to match that of AdminSDHolder every time the thread runs on the PDC Emulator.   We then had to set the adminCount attribute of the accounts from 1 to 0 (Zero) so that SDProp would stop running for the accounts, and then finally re-enable inheritance on the accounts.   This we did in their test forest with some test accounts, but the process will be repeatable for them in their production forest.   We were then able to verify that these accounts with membership in Account Operators could now manage each other, but had no rights for any of the other protected groups (such as Domain Admins).

Before we move onto the second half of our solution, I want to share some links and references to the words SDProp, AdminSDHolder, and dsHeuristics which I so casually threw around in that previous paragraph.  

 

After that bit of fun reading, we then started to look at their second business requirement.   They wanted the staff of their NOC (who are members of Account Operators) to have the ability to unlock the accounts of Domain Admins should these people find themselves needing such a task performed.   This was the last reason why their NOC Leads were members of Domain Admins.   We looked at KB 279723 for guidance and used the following command to grant the Unlock right to the AdminSDHolder object so that the SDProp process would set it onto the members of Domain Admins (and the other protected groups):

  • dsacls "CN=AdminSDHolder,CN=System,dc=corp,dc=contoso,dc=com" /I:T /G "domain\GroupNameForNOCUsers":rpwp;lockoutTime

We couldn’t use the Account Operators group in that dsacls command, so we used the group of their NOC Users which was nested within it.   At this point, once SDProp ran again, the users could then unlock the Domain Admins but could do no other management tasks for these accounts.   This met their needs and allowed us to remove their NOC Leads from the Domain Admins group.

The customer was then able to begin looking at the other accounts within the Domain Admins group and begin to plan out ways to delegate the required rights so that many of those accounts could be removed as well.