Active Directory Delegation Best Practices

{{ firstError }}
We care about security of your data. Privacy Policy

What is Active Directory (AD) Delegation?

AD delegation enables you to grant users the permissions 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 the process of 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 proper responsibilities. For practical delegation control, you should limit yourself to a small, manageable number of roles. Getting the balance right can be tricky: 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 — Responsible for top-level service administration across the enterprise. Should contain no permanent members.
    • Domain Admins — Responsible for top-level service administration across the domain. Should contain only a small, manageable number of trusted administrators.
    • Tier 4 Admins — Responsible for service administration across the domain. Granted only the accessrights requires to manage necessary services and features. Serve as an escalation point for data administrators.
  • Data administrators:
    • Tier 1 Admins — Responsible for general management of directory objects, including performing password resets, modifying user account properties, and so on.
    • Tier 2 Admins — Responsible for the selective creation and deletion of user and computer accounts for their location or organization.
    • Regional Admins — Responsible for the management of their local OU structure. Granted permissions to create most objects within their OU.
    • Tier 3 Admins — Responsible for management of all data administrators. Serve as top-tier helpdesk and escalation point 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. 

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 are laid out, you should define your OU and securitygroup 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 scope of management for Tier 4 Admins. With a top-level OU in place, 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 that has a discrete data management team. Each regional sub-OU should have a common, non-extensible OU hierarchy for management of 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 restriction of management 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 have the ability to perform only the tasks required for its roles and nothing more. Basically, all admins must normally log in as average users and use their privileged rights only when they need them.

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 an alternate set of 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 these 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.
  3. On the wizard's Users or Groups page, click the Add button.
  4. In the Select Users, Computers or Groups dialog box, enter the group's name (Help Desk), click the Check Names button to make sure the name is correct, and click OK.
  5. Make sure the selected group's name is now in the list on the Users or Groups page, and click Next.
  6. On the Tasks to Delegate page, select Create, delete, and manage user accounts and click Next.
  7. Verify the information on the final page of the wizard and click Finish.

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

AD Delegation Best Practices

  • For delegation to be successful, OUs must be designed and implemented properly and the correct objects (users, groups, computers) must be placed in them.
  • Don't use built-in groups; they give privileges that are too wide in the domain. Instead, create new groups 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 on 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, gain access to sensitive data or change security settings.
  • Consider transferring away 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 your attack surface.
Related best practices