Active Directory Delegated Permissions Best Practices

We never share your data. Privacy Policy

Step 1: Create Roles and Assign Responsibilities

The first thing you need to do is to create a set of administrator roles and assign them proper responsibilities. 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 rights necessary to manage necessary services. 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 locale 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 help desk and escalation point for all regional admins.

Step 2: Define OU Security Model

  • Once roles are defined in the organization, 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 OU serves the specific purpose of defining the highest-level scope of management for the Tier 4 Admins. With a top-level OU in place, rights over the directory service can start explicitly 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 3: Establish a Delegation Model

  • The key to a successful delegation model is enforcing the principle of least privilege. In practice, this means that each security principal should have the ability to perform only the tasks required for its given role and nothing more. Basically, all admins must normally log in as average users and use their privilege 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.
  • The final step in developing a delegation model is the actual delegation of rights within Active Directory (AD). 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.

How to Delegate Administrator Privileges in Active Directory

The Delegation of Control Wizard provides an easy way to delegate active directory management. 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 to advance past the wizard's welcome page.
  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 group's name is correct, and click OK.
  5. After making sure the group's name is listed on the Users or Groups page, click Next.
  6. On the Tasks to Delegate page, select "Create, delete, and manage user accounts" and click Next.
  7. Verify the information in the final page of the wizard and click Finish.

Other 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. Your delegation design must include the creation and location of 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 administrator privileges to different levels in AD.
  • Perform yearly audits on who has which AD delegate controls. There is a free tool to view delegated permissions in Active Directory, it is called Netwrix Effective Permissions Reporting Tool.

What is Active Directory Delegation?

AD delegation is critical part of security and compliance. By delegating control over active directory, you can grant users or groups the permissions they need without adding users to privileged groups like Domain Admins and Account Operators. The simplest way to accomplish delegation is to use the Delegation of Control Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers (ADUC) snap-in.

Though the task of developing an Active Directory delegation model may seem complex, the truth is that very simple models can be applied to most IT infrastructures. One of the most important steps in deploying a practical delegation model is to define clear roles. You should limit yourself to a small, manageable number. The balance is tricky: Having too many roles will result in roles not being used, while having too few roles won't allow for role separation.

When defining tasks, categorize them by frequency, importance and difficulty. Develop a set of use cases to help identify what each role can and cannot do, and automate the process of testing to ensure each role works as intended. Well-prepared use cases will help you explain these roles to the stakeholders in your organization and prevent surprises due to automation errors.

Finally, it's always a good idea to take a practical approach when developing a delegation model. Remember, simplicity equals supportability, and a sustainable delegation model will pay huge dividends by enabling you to properly and efficiently control delegated domain admin rights in your Active Directory environment. And dont forget to regularly determine all active directory delegated permissions and analyze them for actuality.