Active Directory Delegation Best Practices

Delegating control over specific network parts allows users to access the data necessary for their work. However, providing unrestricted access to everyone can pose significant cybersecurity risks for an organization. Active Directory delegation can effectively restrict access to only what users require.

Follow the Active Directory delegation best practices below to protect your network.

What is Active Directory Delegation?

Active Directory (AD) delegation enables you to permit users to perform tasks that require elevated permissions — without adding them to highly privileged groups like Domain Admins and Account Operators. To delegate control in Active Directory, you can use the Delegation of Control Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers (ADUC) snap-in.

How to Develop an AD Delegation Model

It’s best to take a practical approach to delegating rights. Remember, simplicity equals supportability, and a sustainable delegation model will pay huge dividends by enabling you to properly and efficiently control Active Directory delegated permissions.

Step 1: Create Roles

The first step in developing an Active Directory delegation model is to create a set of administrator roles and assign them the correct responsibilities. Limit yourself to a small, manageable number of roles for practical delegation control. Getting the balance right can be challenging because having too many roles adds complexity and management overhead, but having too few roles won't allow for role separation. 

Best practices suggest using the following roles:

Service administrators:

• Enterprise Admins are responsible for top-level service administration across the enterprise. This group should contain no permanent members.
• Domain Admins are responsible for top-level service administration across the domain. This group should contain only a small, manageable number of trusted administrators.
• Tier 4 Admins are responsible for service administration across the domain. The access rights granted allow for the management of only necessary services and features and serve as an escalation point for data administrators.

Data administrators:

• Tier 1 Admins are responsible for general managing directory objects, including performing password resets, modifying user account properties, etc.
• Tier 2 Admins are responsible for the selective creation and deletion of user and computer accounts for their location or organization.
• Regional Admins are responsible for managing organizational unit (OU) structure and have granted permissions to create most objects within their OU.
• Tier 3 Admins manage all data administrators and serve as top-tier helpdesk and escalation points for all regional admins.

Step 2: Assign Responsibilities

Next, develop a set of use cases to help identify what each role can and cannot do. Well-prepared use cases will help you explain the roles to the stakeholders in your organization and ensure proper role assignment. When defining responsibilities, categorize them by frequency, importance, and difficulty. 

Active control lists (ACLs) on Active Directory containers define what objects can be created and how those objects are managed. Delegation of rights involves basic operations on objects, such as the ability to view an object, create a child object of a specified class, or read attribute and security information on objects of a specified class. Besides these basic operations, Active Directory defines Extended Rights, which enable operations such as Send As and Manage Replication Topology.

Automate the process of testing to ensure that each role works as intended.

Step 3: Define an OU Security Model

Once your roles and responsibilities have been established, you should define your OU and security group model. A top-level OU (or series of OUs) should be created directly beneath the domain to house all objects. This top-level OU serves the specific purpose of defining the advanced-level management scope for Tier 4 Admins. With a top-level OU, rights over the directory service can start at the OU level rather than at the domain level. 

Below the top-level OUs, you should create separate sub-OU hierarchies to represent each region or business unit with a discrete data management team. Each regional sub-OU should have a standard, non-extensible OU hierarchy for managing directory objects.

Finally, to prevent administrators from escalating their privileges, create separate sub-admin groups — a Tier 1 Admins, a Tier 2 Admins, and a Regional Admins group for each sub-OU hierarchy — and put appropriate accounts in each group. Placing these accounts in separate OUs enables management to be restricted to their level or below.

Step 4: Control How Delegated Rights Are Used

The key to a successful delegation model is enforcing the principle of least privilege. In practice, this means that each security principal (such as a user or service account) should be able to perform only the tasks required for its roles and nothing more. All admins must log in as average users and use their privileged rights only when needed.

To accomplish this without requiring the user to log off and back on, use the Secondary Logon service (Runas.exe). This enables users to elevate their privileges by providing alternate credentials when executing scripts or other executables on servers and workstations.

How to Delegate Administrator Privileges in Active Directory

The Delegation of Control Wizard provides an easy way to delegate permissions in Active Directory. For example, suppose you want members of the Help Desk group to be able to create, delete, and manage user accounts in the All Users OU in your AD domain. To do this, you need to perform the following steps:

1. Open the Active Directory Users and Computers console.
2. Right-click the All Users OU and choose Delegate Control. Click the Next button within the Delegation of Control Wizard.
3. Click the Add button on the Wizard's Users or Groups page.
4. In the Select Users, Computers, or Groups dialog box, enter the group's name (Help Desk), click the Check Names button to ensure the name is correct, and click OK.
5. Make sure the selected group's name is now on the Users or Groups page list, and click Next.
6. Select Create, delete, and manage user accounts on the Tasks to Delegate page and click Next.
7. Verify the wizard's final page information and click Finish.

You can confirm that the permissions were written correctly by checking the Security tab of the target OU’s properties.

Considerations When Delegating Specific Permissions

Delegation in Active Directory allows organizations to grant permissions users typically would not have without adding them to privileged groups. However, companies must consider a few things when delegating permissions. 

For example, a good Organizational Unit (OU) design plays a critical role in AD delegation. Then, with that OU or set of OUs, establish tiers for security. In each tier, you should grant the least privileged access. Least-privilege access limits what users can do to only the bare minimum required for their work. Least-privilege access is the key to an organization's cybersecurity, as it limits the number of people who have access to critical data.

For instance, an organization may restrict password reset or unlock permissions, grant permissions to modify only telephone numbers, delegate group membership management Active Directory to specific users, and so on. 

It is also in a company's best interest to avoid using built-in groups (including Enterprise Admins or Domain Admins) since those groups may have robust, wide-ranging permissions. Instead, delegating active directory permissions in tiers and performing regular audits of privileged access is better. 

AD Delegation Best Practices

Follow these guidelines to use Active Directory Domain Services successfully and delegate appropriately.

• For delegation to be successful, OUs must be designed and implemented correctly, and the correct objects (users, groups, computers) must be placed in them.
• Don't use built-in groups; the privileges within the domain are usually too broad. Instead, new groups should be created that are designed solely for delegation.
• Use nested OUs. There will be various levels of data administrators within AD. Some will be delegated control over an entire data type, such as servers — and others might be given only a subset of a data type, such as file servers. This hierarchy is established by creating OUs and sub-OUs, with the delegated administration at the top having more privilege than those lower in the OU structure.
• Perform regular audits to see who has been given delegated administrative privileges to different levels in AD.
• Perform yearly audits on who has which Active Directory delegated controls.
• Audit your environment for suspicious activity that could be a sign of compromise or misuse of delegated rights, such as attempts to elevate privileges to control computer objects, gain access to sensitive data through the network, or change or remove security settings (such as password requirements).
• Consider transferring from a delegation model that relies on standing privileges to a PAM strategy with just-in-time access. That way, you can avoid abuse or malicious use of standing access rights, improve control over privilege use, and significantly reduce the surface of your attack.