Post cover image

July 7, 2026

Breaking the Domain Admin Habit: Implementing Granular Active Directory OU Delegation of Control

Stop relying on dangerous, built-in administrative groups. Learn how to write surgical Access Control Entries (ACEs) directly onto an OU’s…

By Aayushbhatt

7 min read

Stop relying on dangerous, built-in administrative groups. Learn how to write surgical Access Control Entries (ACEs) directly onto an OU's security descriptor to achieve absolute least privilege.

Core Concept Overview

Shifting from Privilege Escalation to Delegated Scoping

One of the most persistent operational flaws in identity management is the over-provisioning of administrative capabilities. When IT staff require permissions to handle baseline support tasks — such as resetting user credentials, unlocking locked profiles, or provisioning new workstations — organizations frequently default to adding these users to highly privileged groups like Domain Admins or Account Operators. This practice is a severe violation of the principle of least privilege and unnecessarily expands an organization's attack surface.

Active Directory OU Delegation of Control bridges this security gap. Instead of changing a user's group token to elevate their privilege tier across the entire domain, delegation modifies the security descriptor of a target Organizational Unit (OU). By attaching explicit Access Control Entries (ACEs) directly to an OU's Discretionary Access Control List (DACL), you grant specific, narrowly scoped capabilities to a security group within that container boundary only, leaving them with zero rights anywhere else in the directory tree.

None 
┌────────────────────────────────┐
                     │   Active Directory Domain Root │
                     └───────────────┬────────────────┘
                                     │
         ┌───────────────────────────┴───────────────────────────┐
         ▼                                                       ▼
┌─────────────────────────────────┐                    ┌─────────────────────────────────┐
│        OU=Finance (DACL)        │                    │          OU=IT (DACL)           │
├─────────────────────────────────┤                    ├─────────────────────────────────┤
│ • G-Helpdesk-PasswordReset:     │                    │ • G-ITManagers-OUAdmin:         │
│   [Allow: Reset Password]       │                    │   [Allow: Create Computers]     │
│ • Deny-by-default for other     │                    │ • G-Helpdesk-PasswordReset:     │
│   administrative modifications  │                    │   [Allow: Reset Password]       │
└─────────────────────────────────┘                    └─────────────────────────────────┘

The Architecture of Directory ACLs

Every container and object in Active Directory functions identically to a file folder in an NTFS file system. When you run administrative commands to delegate access, you write explicit permissions onto the underlying object metadata database. This structural model provides several critical operational advantages:

  • Property-Level Granularity: Delegation permits you to target specific attributes of a distinct object class. For example, you can grant a helpdesk group the right to write to the lockoutTime attribute (the exact trigger behind unlocking an account) without giving them the right to modify the member attribute of a security group.
  • Hard Containment Boundaries: The scope of a delegated ACE is firmly bound to the target OU. A helpdesk group delegated rights within the OU=Sales container cannot read or modify objects inside the OU=Finance container.
  • Audit Isolation: Because delegated privileges exist purely on the object ACLs rather than within a privileged group's membership database, these configurations are completely separated from broad domain group audits. They require dedicated, focused ACL review disciplines.
  • Controlled Blast Radius: Revoking a delegated capability requires removing a single ACE from an OU's security descriptor. This surgical approach prevents the invisible, system-wide dependencies that frequently break environment scripts when an account is stripped of broad Domain Admins rights.

Real-World Enterprise Use Case

Consider a mid-size corporate banking domain (Bhatt.com) where the internal IT support team needs to handle common helpdesk tickets—such as managing credential renewals and clear account lockouts—for personnel distributed across the Finance and Sales units. Historically, helpdesk teams are dropped into the built-in Account Operators group to expedite these tasks. However, Account Operators carries dangerous domain privileges, including the ability to create and delete users across the domain and sign into Domain Controllers interactively.

To mitigate this risk, the IAM team implements a multi-tier directory delegation model:

  • The Helpdesk Tier (G-Helpdesk-PasswordReset): Receives narrow Reset Password and account unlock capabilities across the Finance, IT, and Sales employee user OUs.
  • The Decentralized Manager Tier (G-ITManagers-OUAdmin): Granted to specific IT managers (e.g., bh1013) to manage computer object lifecycles and modify group memberships exclusively inside the local IT OU hierarchy, keeping them completely isolated from the company's financial and sales identities.

This lab completely avoids the standard GUI Delegation Wizard. The wizard often creates overly broad permission bundles by default. Instead, we deploy explicit configurations using the command-line utility dsacls to ensure strict, auditable precision.

Detailed Step-by-Step Procedure

Execute these administrative commands inside an elevated PowerShell or command instance on your primary domain controller (DC01).

Step 1: Provision the AGDLP Delegation Groups

Following proper role abstraction governance, administrative rights must always be granted to a security group rather than an individual user account.

# Create the global helpdesk delegation group inside the IT container hierarchy
New-ADGroup -Name "G-Helpdesk-PasswordReset" `
            -GroupScope Global `
            -GroupCategory Security `
            -Path "OU=Groups,OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com" `
            -Description "Delegation Group: Authorized for domain password resets and account unlocks"
# Create the global IT management delegation group
New-ADGroup -Name "G-ITManagers-OUAdmin" `
            -GroupScope Global `
            -GroupCategory Security `
            -Path "OU=Groups,OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com" `
            -Description "Delegation Group: Authorized for localized IT computer object lifecycle and group updates"
# Populate the delegation roles with designated employee IDs
Add-ADGroupMember -Identity "G-Helpdesk-PasswordReset" -Members "bh1003", "bh1005", "bh1024", "bh1025", "bh1039", "bh1041"
Add-ADGroupMember -Identity "G-ITManagers-OUAdmin" -Members "bh1013"
  • Expected Verification: Run Get-ADGroupMember against both groups. Confirm that G-Helpdesk-PasswordReset contains the six target helpdesk operators, and G-ITManagers-OUAdmin contains only the manager account (bh1013).

Step 2: Implement Scoped Password and Account Unlock Rights

Deploy the precise, property-specific ACEs across your Finance, IT, and Sales user OUs using the dsacls command utility:

# Target arrays representing target corporate organizational layers
$targetOUs = @(
    "OU=Users,OU=Finance,OU=BHATT-CORP,DC=Bhatt,DC=com",
    "OU=Users,OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com",
    "OU=Users,OU=Sales,OU=BHATT-CORP,DC=Bhatt,DC=com"
)
$trustee = "Bhatt\G-Helpdesk-PasswordReset"
# Atomically inject security descriptors down the tree hierarchy
foreach ($ou in $targetOUs) {
    # CA;Reset Password;user -> Grants Control Access rule to execute password changes on user objects
    dsacls $ou /I:S /G "$($trustee):CA;Reset Password;user"

    # WP;lockoutTime;user -> Grants Write Property right to clear the lockout time tracking attribute
    dsacls $ou /I:S /G "$($trustee):WP;lockoutTime;user"
}
  • Expected Verification: Run dsacls "OU=Users,OU=Finance,OU=BHATT-CORP,DC=Bhatt,DC=com". The returned object descriptor list must explicitly register the G-Helpdesk-PasswordReset string, showing inherited inheritance (/I:S) mappings for the user object attributes.

Step 3: Implement Localized Computer and Group Update Management

Write the broader infrastructure management ACEs strictly onto the local IT OU, establishing a clear administrative perimeter:

$itOU = "OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com"
$mgrTrustee = "Bhatt\G-ITManagers-OUAdmin"
# CCDC;computer -> Grants Create Child / Delete Child rights exclusively for computer object classes
dsacls $itOU /I:S /G "$($mgrTrustee):CCDC;computer"
# WP;member;group -> Grants Write Property on group membership fields inside the IT Groups sub-OU only
dsacls "OU=Groups,OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com" /I:S /G "$($mgrTrustee):WP;member;group"
  • Expected Verification: Run a verification query to check the security configuration on the IT OU path:
dsacls "OU=Groups,OU=IT,OU=BHATT-CORP,DC=Bhatt,DC=com" | Select-String "G-ITManagers-OUAdmin"

The output stream must display a valid WP;member;group mapping, confirming that your IT managers can alter local group lists without gaining global domain admin rights.

Step 4: Run a Negative-Scope Validation Check

To ensure least privilege is genuinely enforced, perform a negative-scope check from a non-privileged staging endpoint (Computer-01) using a helpdesk account:

# Authenticate onto Computer-01 using a helpdesk operator credential (bh1003)
# Test 1: Intended Task (This MUST succeed within delegated scopes)
Set-ADAccountPassword -Identity "bh1004" -Reset -NewPassword (ConvertTo-SecureString "TempPass2026!" -AsPlainText -Force)
# Test 2: Unintended Out-of-Scope Task (This MUST completely fail)
Add-ADGroupMember -Identity "G-Finance-PayrollAccess" -Members "bh1004"
  • Expected Verification: Test 1 must complete cleanly without throwing an error. Test 2 must be instantly rejected by the Active Directory security engine, throwing an explicit Access Denied (Insufficient Access Rights) exception. This verification confirms that the helpdesk group cannot manipulate adjacent sensitive business objects.

Step 5: Log the Active Delegation Configuration Model

Document the active permissions configuration map in your local directory repository file at C:\IAM-Docs\Day9-DelegationModel.txt for future compliance and governance reviews:

================================================================================
BHATT.COM IDENTITY SECURITY ARCHITECTURE — DELEGATED CONTROL LOG
================================================================================
REGULATORY COMPLIANCE TARGET: Least-Privilege Access Enforcement

[DELEGATION SCHEMATIC 1 — GENERAL HELPDESK TIERS]
  Identity Object : G-Helpdesk-PasswordReset
  Active Boundary : OU=Users,OU=Finance | OU=Users,OU=IT | OU=Users,OU=Sales
  ACE Definitions : Control Access (CA) -> Reset Password
                    Write Property (WP) -> lockoutTime
  EXCLUDED RIGHTS : User Creation, User Deletion, Group Membership Modifications
[DELEGATION SCHEMATIC 2 — LOCALIZED MANAGEMENT BOUNDARIES]
  Identity Object : G-ITManagers-OUAdmin
  Active Boundary : OU=IT (Computers) | OU=Groups,OU=IT (Group Membership)
  ACE Definitions : Create/Delete Child (CCDC) -> Computer Objects
                    Write Property (WP) -> Group 'member' Attribute
  EXCLUDED RIGHTS : Cross-OU Modifications, User Account Provisioning
ENVIRONMENT STATUS:
  Negative-scope validation drills completed successfully on Computer-01.
  Out-of-scope group changes are blocked with an explicit Access Denied error.
================================================================================

Section 4 — Interview-Prep Q&A

Q1: A tier-1 helpdesk team requests to be added to the built-in Account Operators group to manage basic support tickets. How would you evaluate this request, and what architecture change would you recommend instead?

Strong Answer: I would reject the request to use the built-in Account Operators group. While it provides the helpdesk with the ability to handle password resets and clear lockouts, it also expands their administrative capabilities far beyond what is required for their roles. Members of Account Operators can create and delete user, group, and computer objects domain-wide, and can log into domain controllers interactively. This presents a severe security risk if a helpdesk credential is compromised.

Instead, I would recommend creating a dedicated security group and applying OU-scoped delegation. Using the command-line utility dsacls, I would grant that group specific Reset Password control access and write rights to the lockoutTime attribute, targeted exclusively to the specific OUs they support. This fulfills their operational requirements while completely preventing out-of-scope modifications or access to domain controller consoles.

Q2: Is there an architectural difference between using the GUI Delegation of Control Wizard and writing permissions via dsacls or PowerShell? Why would an auditor care about the chosen deployment method?

Strong Answer: Functionally, both deployment methods write the exact same underlying Access Control Entries (ACEs) onto the object's security descriptor inside the Active Directory database.

However, from an access governance and auditing standpoint, the deployment method matters significantly. The GUI Wizard bundles multiple discrete permissions behind high-level checkboxes (such as "Manage user accounts"). This abstraction makes it very easy for administrators to accidentally over-provision capabilities without realizing what exact permissions are being written.

Using script-driven tools like dsacls or PowerShell's Set-Acl requires you to explicitly state the exact object class, attribute, and trustee group for every permission entry. This programmatic approach forces explicit engineering decisions and provides a verifiable command-line execution log that acts as an audit trail of administrative intent.

30-Day IAM Sprint Progress Tracker

Phase 1: Foundational Identity Lifecycle & Access Control — ✅ Complete (Days 1–7)
Phase 2: Privileged Access, Delegation & Tiering Architectures — In Progress
[█████████░░░░░░░░░░░░░░░░░░░] 30.0% Complete (9/30 Days)
  ✅ Day 1 — AD DS Logical Structure & Enterprise OU Design
  ✅ Day 2 — User Lifecycle Management — Joiner Phase (JML)
  ✅ Day 3 — Group Strategy & AGDLP Nesting Model
  ✅ Day 4 — GPO for Access Control Enforcements
  ✅ Day 5 — Fine-Grained Password Policies (PSOs)
  ✅ Day 6 — NTFS & Share Permissions, ABAC Introduction
  ✅ Day 7 — Phase 1 Capstone — End-to-End JML Simulation
  ✅ Day 8 — Least Privilege Deep Dive — Built-in Groups & Attack Surface
  ✅ Day 9 — OU Delegation of Control Engineering (Complete)
  ⬜ Day 10 — RBAC Design & Access Matrix Documentation
  ⬜ Day 11 — Microsoft Administrative Tiering Architecture (Tier 0/1/2)

🛠️ Explore the Complete Lab Environment

Access the complete, production-vetted Day 9 deployment scripts, delegation templates, and security configuration code inside our active GitHub Repo. Clone the repository today to instantly build out your local test lab!