Active Directory security and permissions delegation is one of the most important functions for any IT pro, especially when the service is managed by different groups of administrators. While this is more common in medium to large businesses, the same concept can be applied in smaller environments where some sort of delegation may be required.
A single Active Directory can have up to 800 domain controllers, and each domain controller can create up to 2.15 billion (yes, with a “b”!) objects during its lifetime. That says a lot, and with those numbers we know that a single domain can handle a lot of objects. That is a good scenario for many companies, and for this kind of environment the planning of the security and proper delegation becomes a key area to be developed. Here is an official link explaining the Active Directory limits.
In larger environments, we may have several domains. Using this approach, each domain can have its own set of administrators and the delegation can happen at a more granular level within the the domain or at domain level as well.
How can we start with security delegation in Active Directory? The process is simple, but it involves some key features of Active Directory, such as:
- Organization Units (OUs)
- Delegation Wizard
- Group Policies
The level of delegation that we want to implement dictates which features we are going to use. For this article we will focus on Active Directory delegation where a special group of users can perform some management tasks in some locations. In a future article, we will cover the portion that delegates security at the server level.
Scenario
Let’s use a simple scenario to show some of our ideas to implement Active Directory through the delegation process. Our scenario is a multinational corporation with a single domain, and in each country there are some cities where our company is active. All servers, users, and computers are located physically at the city level, never at the country level.
The local administrators will be able to manage users and groups objects at the city level for certain local administrators; also, a country administrator will be a group of users who are able to manage the same objects, but in all cities within that country.
Consistency is the key
Before implementing delegation, we need to design and plan the Organization Unit (OU) structure. OUs are the key feature used to separate logical objects (similar to folders in a file server) and allow the administrator to delegate permissions based on users/groups.
Based on our scenario, we are going to use an OU for each country where our business has a presence. Underneath this layer, we will have the second layer that is going to be the cities where we have Active Directory objects. At the country level, we will have Admin, Cities and Groups, and at the city level we will have the actual resting place for the objects: Computers, Servers, and Users.
A security best practice is to use a separate account for administrators and another for regular access. All the administrator accounts should be created on the Admin OU at the country level.
Planning the security to support security delegation
In our scenario, we have a small group of domain admins, and they are responsible for performing the initial delegation to new countries/cities that are added to the infrastructure. After that, the local team will be responsible for handling users, servers, and computers.
My advice is to create a separate OU at the root level to keep all security groups that will receive delegation at the country/city level. The reason behind is simple: only the domain admins will be able to manage group membership. By doing this, the solution becomes secure by default.
For this article series, we are going to create an OU called Global Services and underneath that we are going to create two OUs: Service Accounts and Applications. The Service Accounts OU can have OUs per country, and all service accounts of those countries could be stored on that location. The Applications OU will be used to store groups that manage Active Directory applications. The first demand would be ADSec, where we are going to store the groups that we creating to delegate our Active Directory administration.
Now that we have an idea what our Active Directory structure will look like, we can start planning how we are going to delegate permissions. My advice is to always to use Groups, because doing it per user is just painful, and, believe me, you will regret it after a second user with the same permission is required. The naming convention is important to keep the administration simple, so with a simple glance the administrator can identify where that group is being used.
In this article, we are going to use the first two to six characters to identify the Country or the City (which will have the Country prefix). The suffix will be the same: –Admins. For example: CA-Admins is the group of administrators able to manage Canada and the cities within; at the same time a group like CATOR-Admins is responsible for managing objects only at the Toronto Organization unit level.
I like to spend some time on the naming convention for any new implementation, and you should, too. Another possible suggestion for this schema is to add a prefix such as ADSec. This way the administrator can always match the group name with the OU and location.
Delegating permissions
The delegation process wizard can be triggered from the Active Directory Users and Computers, and the delegation can be assigned using preconfigured tasks (known as Common Tasks) or by creating a custom delegation task.
We will delegate at the country level on this section. The same logic applies to the city level.
Logged on the Active Directory Users and Computers, right-click on the desired Country, in our case Canada, and then click on Delegate Control… . In the welcome page of the wizard, just click Next.
In the Users or Groups page, click on Add… and type in the group name, in this case CA-Admins, and click Next.
In the Tasks to Delegate page, make sure that the country administrators are allowed to manage user accounts and manage groups. Click Next and Finish.
In the previous step, we delegated the ability to manage user and group accounts. But we haven’t touched the ability to manage computer accounts. To do that, we can create the same wizard, but at this time we will select Create a custom task to delegate. The next page will be slightly different.
Now we will have a list of all objects that we want to manage. Select Computer objects, and then select Create selected objects in this folder and Delete selected objects in this folder, and then click Next.
Let’s move on to the Permissions page. Because we are using a custom delegation task, we can define the permission on the previous object we selected. In this case we will allow full control of the computer objects (item selected from the previous page). Click on Next and Finish.
At this point, we have the CA-Admins group with permission on all OUs underneath Canada structure in Active Directory to manage computers, users, and groups objects. We can repeat the same process at the city level by delegating to another group. For example: Toronto would delegate permissions to CATOR-Admins group.
If at the city level the local administrators require fewer permissions, we can reduce and customize the permission as we want by selecting common delegation tasks available or customizing them.
Keep in mind that we are assigning permissions at the parent level (country or city) and that applies to all sub-OUs, and that gives room for an administrator to create a user on a different OU than Users, which may be a problem in some scenarios. If that is the case, then it is better to delegate permissions at the sub-OU level. For example: delegate group capabilities only to the Groups OU. The same logic applies to users and computer objects.
Photo credit: FreeRange Stock
