Active Directory Delegation Best Practices

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.