50 Shades of Administration - Managing Domain Admin Privileges

50 Shades of Administration

During our work, both our auditors and engineers have noticed a common issue our clients large and small have - overly permissive administration accounts.  Many times, we see all IT users given a Domain Admin account, from the greenest helpdesk tech, to the person overseeing the network.  Microsoft's Active Directory has a couple of different ways to grant rights to a user, group, or organizational unit, allowing the target the ability to perform certain tasks without giving them the keys to the kingdom.  Here are just a couple simple examples.

Delegation of Control

In the Springfield.local domain, Lisa Simpson has taken an internship with a local bank.  For the duration of her internship, Lisa will mostly be shadowing the in-house IT staff; however, the powers that be have decided she should be able to reset a user's password.  One of the system administrators accomplishes this by delegating control of the Springfield\ SpringfieldUsers Organizational Unit (OU) to the Interns security group.

Figure 1: Right-click menu for SpringfieldUsers OU

Figure 2: Delegation of Control group selection

Figure 3: Delegation of Control task(s) selection

A plethora of tasks can be delegated here, allowing users the ability to perform common (and not so common) Active Directory functions.  The creation, deletion, and management of user accounts and groups, as well as some Group Policy management is shown in the screenshot above, with more predefined tasks available as well.  You can also create your own tasks, should you need that functionality.

Once this is accomplished, the next time Lisa logs in, she can change the password for members of the SpringfieldUsers OU:

Figure 4: Lisa's First Password Reset

Figure 5: Setting the new password

Figure 6: Successful password change

Group Policy

So, Lisa's internship progresses to the point where the bank offers her a job.  She accepts, and becomes a member of the bank's Helpdesk team.  Members of this team are given local administration access to the workstations on the network.  This is accomplished through a more traditional method - Group Policy.

Adding users or groups from Active Directory to a group on a workstation is a straightforward exercise.  In Group Policy, create a new GPO or edit an existing one, and under Computer Configuration find Policies\Windows Settings\Security Settings\Restricted Groups.  Add the Active Directory group to the area on the right, and then add the name of the local group you wish to modify to the bottom box in the window that pops up.

Figure 7: Adding a custom domain group to a local group

Once you click apply, you should see something like this:

Figure 8: Result of group addition

Once the workstations affected by the GPO pick up the updated policy, members of (in this case) the Springfield\WorkstationAdmins group will have local administrator rights to the workstations.

Naturally, Lisa excelled at the bank and was soon made a system administrator.  This came with a domain administrator account in addition to her normal user account, and Lisa could help keep the bank's network secure for years to come.

While the story may be slightly extremely rather cheesy, the IT staff of the bank have a decent system in place to allow their more technical employees to perform tasks in Active Directory to assist users while minimizing the impact of the compromise of any one user's credentials below a Domain Admin level.  Lisa is able, during her internship, to reset user passwords, taking some of the load off the support team while still being able to shadow the techs as they go about their day.  Once she joins the Helpdesk full time, she is able assist the users with problems they may be having on their workstations.  Finally, after proving herself, she can administer the entire domain.

It is certainly easier to give everyone in your IT department a Domain Admin account, as by doing that they can perform (except in rare cases) any task they must to assist their users.  The problem, however, is that any one of these credentials, if compromised, provide the attacker with the keys to the kingdom.  Limiting your IT staff to an appropriate level of access to the network will help minimize the damage should one of their credentials be compromised; at the very least, it will make it harder for the attacker to elevate their access to a Domain Admin level.

Naturally, any changes like these that are made to your environment should be tested before rolling them out into production.  A brand-new lab environment is significantly different from the production networks we deal with each day, and other settings in the domain may influence any changes you make to permissions.  A FANTASTIC resource for hardening your Active Directory environment can be found at https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory.  There is a daunting amount of information in this guide, but it should help you (as it did me, thanks Microsoft!) through the process.

Authored By: Daniel Sheridan, CEH

  Download Blog