Delegate OU Permissions Without Making Someone Domain Admin

Effective Active Directory (AD) administration often necessitates distributing management responsibilities without compromising the security of the entire…

Effective Active Directory (AD) administration often necessitates distributing management responsibilities without compromising the security of the entire domain. Granting excessive privileges, particularly Domain Admin rights, to support staff or departmental administrators introduces significant risk. This article details a methodical approach to delegating specific, granular permissions to Organizational Units (OUs) within Active Directory, focusing on common scenarios like helpdesk operations and departmental user management, leveraging both GUI and command-line tools.

The core principle is the principle of least privilege: grant only the permissions necessary to perform a job function, and no more. This minimizes the attack surface and potential damage from accidental misconfiguration or malicious intent.

Understanding Active Directory Permissions

Active Directory permissions are governed by Access Control Lists (ACLs) attached to objects (users, computers, OUs, groups, etc.). Each ACL contains Access Control Entries (ACEs), which define specific rights (read, write, delete, create child objects, modify properties) for a particular security principal (user, group) on that object or its properties. Permissions can be inherited from parent objects or explicitly set.

Key permission types relevant to delegation:

Full Control: Grants all possible permissions, including taking ownership and changing permissions. Avoid this for delegation.
Read/Write All Properties: Allows reading and writing any property of an object. Too broad for typical delegation.
Create/Delete Child Objects: Allows creating or deleting objects (e.g., users, groups) within an OU.
Specific Properties: Allows reading or writing a specific attribute (e.g., userAccountControl for enabling/disabling accounts, sAMAccountName, memberOf for group membership).

Delegating Common Helpdesk Tasks via GUI

The Active Directory Users and Computers (ADUC) console provides a wizard-driven interface for common delegation scenarios. This is the simplest method for basic tasks.

Step-by-Step Delegation with the Control Delegation Wizard

Open Active Directory Users and Computers (dsa.msc).
Navigate to the OU you wish to delegate. For example, if you have an OU named SalesUsers under corp.contoso.com.
Right-click the OU (e.g., SalesUsers) and select Delegate Control....
Click Next on the welcome screen.
On the Users or Groups screen, click Add.... Type the name of the security group that will receive the delegated permissions (e.g., Helpdesk_Sales) and click Check Names, then OK. Click Next.
On the Tasks to Delegate screen, you'll see common predefined tasks. For a typical helpdesk role, select the following:
- Reset user passwords and force password change at next logon
- Read all user information (often implicitly granted or required for other actions)
- Unlock users accounts
- Modify the membership of a group (useful for department-specific groups)
- Create, delete, and manage user accounts (if helpdesk needs to onboard/offboard users within that OU)
If these predefined tasks are insufficient or too broad, choose Create a custom task to delegate for finer control (discussed below).
Click Next, then Finish to apply the delegation.

Example Scenario: A Helpdesk_Sales group needs to reset passwords, unlock accounts, and manage membership of groups located within the SalesUsers OU.


# After running the wizard and selecting the above tasks, the underlying permissions
# are set. To inspect these, you would use dsacls (demonstrated later).
# The wizard typically grants permissions like:
# - Write property: Reset Password (User-Change-Password)
# - Write property: userAccountControl (for account unlock, enable/disable)
# - Write property: member (for group membership changes) on Group objects
# - Create/Delete User objects (if "Create, delete, and manage user accounts" is selected)

Delegating Custom Permissions for Granular Control

When the predefined tasks are insufficient, the wizard allows for custom delegation. This provides access to specific object types and their properties.

Using the Custom Task Delegation Wizard

Follow steps 1-5 from the previous section.
On the Tasks to Delegate screen, select Create a custom task to delegate and click Next.
On the Active Directory Object Type screen:
- This folder, existing objects in this folder, and creation of new objects in this folder: The most common choice, applying permissions broadly within the OU.
- Only the following objects in the folder: Allows you to select specific object types (e.g., "User objects", "Group objects", "Computer objects") to apply permissions to. This is crucial for limiting impact.
For helpdesk, typically you'd select "User objects" and "Group objects" if they manage both.
Click Next.
On the Permissions screen, you have two main sections:
- General: Contains broad permissions like "Read all properties", "Write all properties", "Create/Delete [object type]".
- Property-specific: Lists individual attributes. This is where granularity lies.
  - For password resets, select "Write property: Reset Password".
  - For unlocking accounts, select "Write property: userAccountControl".
  - For modifying group membership, select "Write property: member" (on Group objects) and "Write property: memberOf" (on User objects).
  - For enabling/disabling users, select "Write property: userAccountControl".
Select the appropriate "Write" permissions for specific attributes. For instance, to allow changing a user's phone number but nothing else, select "Write phone number".
Click Next, then Finish.

Example: Delegate only the ability to manage group membership for groups within an OU.

Target OU: OU=Groups,OU=Sales,DC=corp,DC=contoso,DC=com.
Security group: SalesGroupAdmins.
In the custom delegation wizard:
- Select "Only the following objects in the folder", then check "Group objects".
- In permissions, check "Write" for the "member" property.

Verifying Delegated Permissions with `dsacls`

The dsacls.exe command-line utility is indispensable for viewing and manipulating ACLs directly. It provides a detailed breakdown of permissions, which is critical for verification and advanced scripting.

To view permissions on an OU:


dsacls "OU=SalesUsers,OU=Sales,DC=corp,DC=contoso,DC=com"

Output will show ACEs in a format like:


Owner: CORP\Domain Admins
Group: CORP\Domain Admins

DACL:
    Allow BUILTIN\Administrators                      Full Control
    Allow NT AUTHORITY\SYSTEM                         Full Control
    Allow CORP\Domain Admins                          Full Control
    Allow CORP\Account Operators                      Create/Delete User,Create/Delete Group,Create/Delete Computer
    Allow CORP\Helpdesk_Sales                         SPECIAL ACCESS for user objects
            WRITE PROPERTY       userAccountControl
            WRITE PROPERTY       userPassword
            WRITE PROPERTY       sAMAccountName
    Allow CORP\Helpdesk_Sales                         SPECIAL ACCESS for group objects
            WRITE PROPERTY       member

Look for the security group you delegated permissions to (e.g., CORP\Helpdesk_Sales) and verify the specific access rights (e.g., WRITE PROPERTY userAccountControl). Pay close attention to "SPECIAL ACCESS" lines, which indicate granular property-level permissions.

To view permissions on a specific user object:


dsacls "CN=John Doe,OU=SalesUsers,OU=Sales,DC=corp,DC=contoso,DC=com"

This will show both explicitly set permissions and inherited permissions. The dsacls tool is invaluable for auditing and troubleshooting.

Using `dsacls` for Advanced Delegation (Direct ACL Modification)

While the GUI wizard is user-friendly, dsacls offers superior control for complex or automated scenarios. It's often used to refine permissions beyond what the wizard offers or to apply permissions at scale via scripting.

Common dsacls switches:

/G :: Grant permissions.
/D :: Deny permissions.
/I:S: Inherit permissions from parent.
/P : Replace permissions.
/S: Replace object's ACL with an inherited ACL.

Example: Grant a group the ability to modify description and department attributes on User objects within an OU.


# First, create the group if it doesn't exist
# New-ADGroup -Name "SalesDepartmentManagers" -GroupScope Global -Path "OU=Groups,OU=Sales,DC=corp,DC=contoso,DC=com"

# Grant write access to 'description' property on User objects within SalesUsers OU
dsacls "OU=SalesUsers,OU=Sales,DC=corp,DC=contoso,DC=com" /G "CORP\SalesDepartmentManagers":WP;description;user

# Grant write access to 'department' property on User objects within SalesUsers OU
dsacls "OU=SalesUsers,OU=Sales,DC=corp,DC=contoso,DC=com" /G "CORP\SalesDepartmentManagers":WP;department;user

Explanation of the /G switch syntax:

CORP\SalesDepartmentManagers: The security principal (group) receiving the permission.
WP: Write Property access right.
description / department: The specific LDAP display name of the attribute.
user: The object class to which this permission applies. If omitted, it applies to all object types. Other common object classes include group, computer.

For a comprehensive list of LDAP display names, refer to the AD Schema documentation (e.g., User-Description for description). The dsacls utility uses the short form where possible, but the full schema name always works.

Delegating Permissions for Computer Objects

In addition to users and groups, it's common to delegate control over computer objects, for instance, allowing a departmental IT team to add/remove computers from a specific OU or reset their computer accounts.

Using the Delegation Wizard for Computer Objects:

Right-click the target OU (e.g., OU=SalesComputers,OU=Sales,DC=corp,DC=contoso,DC=com) -> Delegate Control....
Add the security group (e.g., Sales_IT).
Choose Create a custom task to delegate.
Select "Only the following objects in the folder" and check Computer objects.
Grant permissions like:
- Create Computer objects (allows joining computers to the domain into this OU).
- Delete Computer objects.
- Reset Password (for computer accounts).
- Validated write to DNS host name / Validated write to service principal name (if the group needs to register SPNs/DNS for applications).

Using dsacls for Computer Object Delegation:


# Grant 'Sales_IT' group ability to create computer objects in the SalesComputers OU
dsacls "OU=SalesComputers,OU=Sales,DC=corp,DC=contoso,DC=com" /G "CORP\Sales_IT":CA;computer

# Grant 'Sales_IT' group ability to delete computer objects in the SalesComputers OU
dsacls "OU=SalesComputers,OU=Sales,DC=corp,DC=contoso,DC=com" /G "CORP\Sales_IT":DD;computer

# Grant 'Sales_IT' group ability to reset computer account passwords
dsacls "OU=SalesComputers,OU=Sales,DC=corp,DC=contoso,DC=com" /G "CORP\Sales_IT":WP;Reset-Password;computer

In the above, CA is "Create Child" and DD is "Delete Child" specific to the computer object class.

Common Pitfalls

Granting "Full Control": The most common and dangerous mistake. It bypasses all granular controls and gives the delegate complete power over the OU and its contents. Never use this for delegation.
Over-delegating "Write All Properties": This is nearly as bad as Full Control for user or computer objects. It allows modification of critical attributes like userPrincipalName, sAMAccountName, and potentially primaryGroupID, which can lead to privilege escalation or account hijacking.
Forgetting "List Contents" or "Read All Properties": While you want to limit write access, users often need to read properties to perform their duties (e.g., view phone numbers, department info). If "Read" permissions are too restrictive, tools might not function correctly.
Delegating to individual users instead of security groups: Always delegate to security groups. This simplifies management and auditing. Add or remove users from the group as job roles change.
Not verifying permissions: Always use dsacls to inspect the resulting ACLs after using the wizard or making manual changes. Relying solely on the wizard's summary can lead to surprises.
Inheritance issues: Be aware of inheritance. Permissions granted at a higher-level OU will flow down unless explicitly blocked or overridden. Plan your OU structure with delegation in mind.