One of the most important -- and often most time-consuming -- tasks of any IP admin is the delegation of permissions and the enforcement of security. This becomes trickier in companies where services are managed by different groups of administrators.
In an earlier article, we covered the delegation process at the Organization Unit level where we controlled the abilities to create objects in Active Directory. In that same article, we created a structure to support delegation in two levels. The level names we used in that article were Country and City.
A benefit of that approach is that we managed all the security delegations using Active Directory groups. This way any new administrator will not require a new delegation wizard to get started. It is simply a matter of adding him or her to an existing Active Directory group.
In this article, we are going a little bit further. We will take advantage of the structure we put in place in the previous article and make sure those same groups can be configured as local administrators on the servers using Group Policies.
Reviewing the scenario
The scenario is simple. We have a multinational company using a single Active Directory domain, and the IT administration is divided in three levels: Global Administrators, who are the Domain Admins/Enterprise Admins (and they are only a few users); Country Administrators, who are able to manage objects and be local administrators on all servers within the country where they reside; and City Administrators, who are able to manage only at their city level.
Each Country has an Organization Unit at the root level in the domain, and then a sub-OU for Cities, and underneath that an OU for each City. In each City, we have the actual computers, servers, and users separated by Organization Unit as well. The permission to create objects at the Active Directory level was already configured in the previous article.
All the Active Directory groups that have delegated permissions on their respective Countries and/or Cities can be found at Global Services / Applications / ADSec Organization Unit. Their name convention represents the Country and City. When there is just the Country code it means that they are Country Administrator. The same rule applies when the prefix of their group has the Country + the City code, and in that case they are City Administrators.
Before starting the configuration, let’s analyze the local Administrators group of any new Windows Server 2012 R2 or Windows Server 2016 server when it is joined to the domain. By default, the group will have the local administrator account and the Domain Admins group from Active Directory.
Our goal is to allow local administration to some servers but at the same time protect the Domain Admins group.
Delegating local administrators to the servers
Now that we have a clear view how our structure was built and where the groups that received the delegation are located, we will use this knowledge and build on top the permissions required to assign local administrators to the servers.
We are going to use a Group Policy combined with the Organization Units to make it happen. The first step is to create an empty Group Policy and associate it at the Server OU at the City level. Let’s start with Canada\Cities\Toronto Organization Unit. We will use a similar naming convention to keep it easy to understand the dependency of the Group Polices, Active Directory groups, and Organization Units. The naming convention that we will use for Group Policies are CATOR-Server Delegation, where CA represents Canada, TOR is Toronto. The suffix will be the same for all locations.
- Log on a Domain Controller, open Group Policy Management Console
- Expand the Forest: infralab.org, org, and select the Organization Unit where we want to apply the new policy. We will be creating at the top of Canada OU. Right-click on it, and then click on Create a GPO in this domain, and Link it here…
- In the new window, type in the name of the new GPO, which in our case will be CA-Server Delegation, and click on OK
- Right-click on the newly created Group Policy, and click on Edit…
As a best practice, right-click on the Group Policy name (first item on the left side) and click on Properties, and on the Properties page, select Disable User Configuration settings. This way we make sure that this policy will be applied only to the computer objects.
- In the Group Policy Management Editor, expand Computer Configuration, Policies, Windows Settings, Security Settings. Right-click on Restricted Groups and click on Add Group…
- In the new dialog box, type in Administrators. This group should match the local administrator on the Servers/Computers where the Group Policy will be applied. Next, click OK.
- In the Administrators properties, we must be aware of some key points before configuring the permissions, as follows:
- If you are using a non-English machine, make sure to type exactly the same name that corresponds to “administrator” in the language you are using;
- Make sure to add Administrator, which is the local administrator of the server that will receive the Group Policy
- Make sure to add the Active Directory groups using DOMAIN\GroupName
- Make sure to add DOMAIN\Domain Admins as part of the group
- In this case, we will add the Country Administrator and the City Administrator to keep consistency of the permissions
If we want to increase the security level, we have two options under Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Local Policies \ User Rights Assignment.
The first option is configuring the Allow log on locally, and all the groups listed here are the only ones that will be able to log on the server’s console.
The second option is Allow log on through Remote Desktop Services. Using this option we can define which groups are able to remote desktop to the given service where the policy is being applied.
Testing the results
Allow some time to wait for the replication to take place among domain controllers, and force the Group Policy update on the server running gpupdate /force.
The results can be checked using compmgmt.msc, and if we check the membership of the local Administrators group we will see all entries that we configured on the Group Policy.
We are done, and now your job becomes easier: When a new administrator arrives on site, just add the user to the desired group, and that will take care of the permissions on all servers of the location.