Delegate Active Directory Admin authorizations

Some readers of this blog have requested an article on delegating admin authorizations. Most of the requests revolve around the fact that certain administrative activities, such as creating user accounts or resetting passwords, should be carried out by users. Of course, these users should not have Domain Admin authorizations, but only the authorizations required for their activities. Requests often revolve around how the administration of entire sites, including group policies, can be delegated to other administrators without them having to be members of the Domain Admins group.

This article is about delegating the management of entire company sites to different administrators. In order for permissions to be delegated within the Active Directory, a structure of the company's organizational units is first required. A corresponding structure cannot be rigidly defined, but should ideally be based on the requirements and organization of the company. Personally, I find it easiest to start with a simple and flat structure and then expand or change the OU structure depending on requirements. Much more important than directly creating an OU structure that is perfectly tailored to the company is the Active Directory security to consider and implement right from the start.

Delegate authorizations

For this example, let's assume a company with two locations (location A and B). The two locations are to be managed by different admins. A site admin should only be able to create and manage users/groups for his site, add computers to the Active Directory and create group policies for the computers. However, as the domain admin, you want to retain control over the authorizations and be able to specify certain basic settings.

A very flat OU structure of the company could therefore look something like this:

Admittedly: The structure is very flat, but you could build on it. As you can see, there are initially two different OU "branches": Administration and Locations, and then there are further OUs under each of these. Later in the article, it will become clear why it makes sense to create a separate "Administration" OU and not to assign the admin users and admin groups to the OUs of the respective location.

The users AdminA and AdminB are each members of the groups "Site A Admins" or "Site B Admins". The groups that contain the Admin user accounts can then be assigned corresponding authorizations:

To give the "Site A Admins" group certain authorizations on the respective site, there is a special wizard in the Active Directory. The "Delegate Control" wizard can be found in the context menu of the OU:

In the wizard, first select the group that is to receive the corresponding authorizations for the location. In this example, it is the "Location A Admins" group:

The next step is to select the authorizations that the site administrators should receive. In this example, the site admins are given the following authorizations, which means that the site admins can create and delete users and groups independently, for example:

If site admins should also be able to manage group policies for the site, the options "Manage Group Policy Links" and "Generate Resultant Set of Policy (Planning / Logging)" should also be activated:

The wizard is now complete and the same procedure can be followed for other OUs:

As site admins should also be able to create and manage computers and contacts within the sites, the wizard must be run again. The "Common Tasks" do not cover this. "Create a custon task to delegate" can therefore be selected in the wizard:

The next step is to select the objects that the site admin is allowed to manage, in this example computers and contacts:

The rights for the previously selected objects are then defined in the last step:

The AdminA user can now create and delete groups, users and computers within the "Location A" OU. AdminA can also manage the group memberships within his location.

If the "Manage Group Policy Links" right has been selected, AdminA can also link existing group policies to location A. However, AdminA cannot create new group policies itself. This procedure makes sense if you want to specify the group policies yourself and the site admin decides which group policies should apply to their site. The site admin can therefore access previously set policies, but cannot change them.

If the site admin should also be able to create their own group policies, this right can also be delegated to the admin group. This is done either via the "Group Policy Management" MMC or by assigning the "Group Policy Creator Owners" group. Here is the way via MMC:

Certain authorizations do not have to be selected, the groups are only added:

Alternatively, the "Site A Admins" and "Site B Admins" groups can also be entered as members of the "Group Policy Creator Owners" group. Both ways lead to the same goal. Personally, I prefer to enter them in the "Group Policy Creator Owners" group (easier to audit / report later).

Working with delegated authorizations

The site administrators are now able to manage their own site. They can create and manage users / groups, change group memberships and add computers to the Active Directory. The site administrators do not have to and must not log on to the domain controller via RDP, but work exclusively with the "Remote Server Administration Tools (RSAT)". The tools can be installed on servers and workstations:

Within the MMC "Active Directory Users and Computers", the location admins can read all OUs and settings, but can only edit them within their location. Here is an example for the user AdminA, who is only allowed to manage location A:

AdminA has no authorizations on other OUs and therefore cannot create new users, for example:

Also, the site admin cannot add users to groups outside his administration area. Here is an example when AdminA tries to add a user to the "Domain Admin" group:

Similarly, when managing group policies, AdminA can link existing group policies to its location and create its own policies. Other OUs cannot be managed:

If a Domain Admin wants to specify certain basic settings for all locations, GPOs can be attached to the higher-level OU and enforced. A site admin cannot then override these settings with their own GPOs:

Before a site admin adds new computers to the Active Directory, the computer objects must first be created in the respective OU (pre-staged):

Without pre-staging the computer accounts, new computers are added to the default OU "Computers", but the site admin cannot manage this OU. Alternatively, computers can be added to AD using PowerShell; the OU can be specified directly using the "Add-Computer" command and the "-" parameter:

• Add-Computer