IAM1.5 Administrative Units and Delegation Boundaries

Why delegation boundaries matter for IAM

In a flat directory — no administrative units, no scoped roles — every administrator with the User Administrator role can modify every user in the tenant. Every administrator with the Groups Administrator role can modify every group. Every administrator with the Helpdesk Administrator role can reset every password. The role defines what the administrator can do. Nothing defines where.

That's a governance problem for three reasons. First, it violates least privilege — the Manchester helpdesk operator who resets passwords doesn't need the ability to reset passwords for the CISO's account or the break-glass admin. Second, it prevents distributed governance — when a multi-site organization wants each site to manage its own identities, a flat directory forces either central control (one team manages everything) or over-privilege (each site's admin has tenant-wide scope). Third, it blocks accountability — when any admin can modify any identity, audit logs show who made a change but not whether the change was within their authorized scope.

Administrative units solve this. An AU is a container in Entra ID that holds users, groups, and devices. You assign admin roles scoped to specific AUs, so the Manchester helpdesk admin can reset passwords only for users in the Manchester AU. The Bristol admin manages Bristol users. The security team manages security-sensitive groups in a restricted AU that even Global Administrators can't touch without explicit self-assignment.

Module 8 builds the full delegation architecture. This section assesses the current state — whether AUs exist, how roles are scoped, and what the delegation gap looks like.

Estimated time: 45 minutes.

Your current AU state — portal view first

Query your tenant programmatically:

Connect-MgGraph -Scopes "AdministrativeUnit.Read.All",
  "RoleManagement.Read.Directory", "Directory.Read.All"

$aus = Get-MgDirectoryAdministrativeUnit -All -Property id, displayName,
  description, isMemberManagementRestricted, membershipType,
  membershipRule

if ($aus.Count -eq 0) {
  Write-Host "Administrative units: 0"
  Write-Host "Delegation model: FLAT — all admin roles have tenant-wide scope."
  Write-Host "Every User Administrator can modify every user."
  Write-Host "Every Helpdesk Administrator can reset every password."
  Write-Host "Module 8 builds the AU structure. This section documents the gap."
} else {
  Write-Host "Administrative units: $($aus.Count)"
  $aus | Select-Object displayName,
    @{N='Type'; E={
      if ($_.IsMemberManagementRestricted) { "Restricted" }
      elseif ($_.MembershipType -eq "Dynamic") { "Dynamic" }
      else { "Standard" }
    }},
    @{N='Members'; E={
      (Get-MgDirectoryAdministrativeUnitMember -AdministrativeUnitId $_.Id -All `
        -ErrorAction SilentlyContinue).Count
    }},
    description | Format-Table -AutoSize
}

Administrative units: 0
Delegation model: FLAT — all admin roles have tenant-wide scope.
Every User Administrator can modify every user.
Every Helpdesk Administrator can reset every password.
Module 8 builds the AU structure. This section documents the gap.

Most tenants return zero. AUs require deliberate design and deployment — they're not created by default, and most M365 implementations skip them entirely. The governance consequence: every privileged role operates without scope constraint.

What AUs enable — the three types

If your tenant does have AUs (or when you build them in Module 8), three types serve different governance purposes.

Standard administrative units

The basic delegation boundary. You create an AU for a site, department, or business unit, add the relevant users and groups, and assign admin roles scoped to that AU. The Manchester helpdesk admin gets Helpdesk Administrator scoped to the Manchester AU. They can reset passwords for Manchester users. They can't touch Bristol, Edinburgh, or Rotterdam users.

Key constraint: adding a group to an AU places the group itself under AU-scoped administration, but the group's members are not automatically added to the AU. An AU-scoped Groups Administrator can manage the group's properties and membership, but an AU-scoped User Administrator can't manage the group's members unless those members are also individually added to the AU. This distinction matters for governance design — if you want site-level delegation where the site admin manages both users and their group memberships, you need to add both the users and the groups to the AU.

Dynamic administrative units

Dynamic AUs use attribute-based membership rules — the same syntax as dynamic group rules. Users are automatically added to and removed from the AU based on attribute values:

# Example: create a dynamic AU for all Bristol users
$params = @{
  DisplayName = "AU-Bristol-Dynamic"
  Description = "All users with officeLocation Bristol"
  MembershipType = "Dynamic"
  MembershipRule = '(user.officeLocation -eq "Bristol")'
  MembershipRuleProcessingState = "On"
}
New-MgDirectoryAdministrativeUnit -BodyParameter $params

Dynamic AUs solve the membership maintenance problem — when a user's officeLocation changes from Bristol to Manchester, they automatically move between AUs. But they inherit the same data quality dependency as dynamic groups. If officeLocation is empty for 30% of users, those users fall outside every location-based dynamic AU. Dynamic AU membership requires P1 licensing for each member.

Restricted management administrative units

The most powerful AU type. Restricted management AUs block all tenant-scoped administrators — including Global Administrators — from modifying objects inside the AU. Only administrators explicitly assigned a role at the restricted AU's scope can manage its members. Even a Global Administrator must explicitly assign themselves to a role scoped to the restricted AU before they can modify anything inside it, and that self-assignment is an auditable event in the directory audit logs.

Use restricted AUs for:

• Executive accounts — the CEO, CFO, and board members whose accounts should only be managed by a designated identity administrator, not by any helpdesk operator with tenant-wide scope.
• Break-glass accounts — emergency access accounts that must be protected from accidental modification or malicious disabling.
• Service accounts with sensitive permissions — accounts holding Global Administrator or other high-privilege roles that should be protected from unauthorized modification.
• Security-sensitive groups — groups that control access to critical applications or assign privileged roles, where membership changes should be restricted to authorized administrators.

# Create a restricted AU for sensitive identities
$params = @{
  DisplayName = "AU-Sensitive-Identities"
  Description = "Executive accounts, break-glass, and high-privilege service accounts"
  IsMemberManagementRestricted = $true
}
New-MgDirectoryAdministrativeUnit -BodyParameter $params

Scoped role assignments — current state

Even without AUs, your tenant has role assignments. The governance question is whether those assignments are scoped (limited to specific AUs) or tenant-wide (unlimited). Query the current role assignments:

$roleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -All `
  -ExpandProperty principal, roleDefinition

$scopedAssignments = $roleAssignments | Where-Object {
  $_.DirectoryScopeId -ne "/"
}
$tenantWide = $roleAssignments | Where-Object {
  $_.DirectoryScopeId -eq "/"
}

Write-Host "=== ROLE ASSIGNMENT SCOPE AUDIT ==="
Write-Host "Total role assignments:  $($roleAssignments.Count)"
Write-Host "Tenant-wide (scope /):  $($tenantWide.Count)"
Write-Host "Scoped (AU or other):   $($scopedAssignments.Count)"

if ($scopedAssignments.Count -eq 0) {
  Write-Host "`nAll role assignments are tenant-wide. No scoped delegation exists."
}

=== ROLE ASSIGNMENT SCOPE AUDIT ===
Total role assignments:  12
Tenant-wide (scope /):  12
Scoped (AU or other):   0

All role assignments are tenant-wide. No scoped delegation exists.

List the high-privilege tenant-wide assignments that the delegation design needs to address:

$highPrivRoles = @("Global Administrator", "User Administrator",
  "Groups Administrator", "Helpdesk Administrator",
  "Exchange Administrator", "SharePoint Administrator",
  "Authentication Administrator", "Privileged Role Administrator")

$tenantWide | Where-Object {
  $_.RoleDefinition.DisplayName -in $highPrivRoles
} | Select-Object @{N='Principal'; E={$_.Principal.AdditionalProperties.displayName}},
  @{N='Role'; E={$_.RoleDefinition.DisplayName}},
  @{N='Scope'; E={$_.DirectoryScopeId}},
  @{N='Assignment'; E={
    if ($_.ScheduleInfo.Expiration.Type -eq "NoExpiration") { "Permanent" }
    else { "Time-bound" }
  }} | Format-Table -AutoSize

Principal      Role                      Scope  Assignment
---------      ----                      -----  ----------
Phil Greaves   Global Administrator      /      Permanent
Phil Greaves   Exchange Administrator    /      Permanent
Phil Greaves   SharePoint Administrator  /      Permanent
Phil Greaves   User Administrator        /      Permanent
Admin Account  Global Administrator      /      Permanent

Phil holds four permanent tenant-wide roles. The admin account (your lab admin) holds Global Administrator. Every one of these is a governance finding: permanent assignment (no PIM activation required), tenant-wide scope (no AU boundary), and multiple roles on a single identity (separation of duties concern from IAM0.3).

Module 7 addresses PIM governance — converting permanent assignments to eligible ones with approval workflows. Module 8 addresses delegation architecture — creating AUs and scoping admin roles to specific populations. This section documents the current state as the baseline for both modules.

Build a test AU in your lab

Even though the full AU architecture comes in Module 8, create one test AU now to understand the mechanics. You'll use it to verify scoped role assignments work as expected.

The equivalent in PowerShell:

# Create the AU
$au = New-MgDirectoryAdministrativeUnit -DisplayName "AU-NE-Bristol" `
  -Description "Northgate Engineering Bristol HQ — test AU for IAM course"

Write-Host "Created AU: $($au.DisplayName) ($($au.Id))"

# Add members
$bristolTeam = @("Rachel Okafor", "Tom Ashworth", "Priya Sharma",
  "Marcus Webb", "Elena Petrova")

foreach ($name in $bristolTeam) {
  $user = Get-MgUser -Filter "displayName eq '$name'"
  if ($user) {
    $memberRef = @{
      "@odata.id" = "https://graph.microsoft.com/v1.0/users/$($user.Id)"
    }
    New-MgDirectoryAdministrativeUnitMemberByRef `
      -AdministrativeUnitId $au.Id -BodyParameter $memberRef
    Write-Host "Added: $name"
  }
}

# Verify
$members = Get-MgDirectoryAdministrativeUnitMember -AdministrativeUnitId $au.Id -All
Write-Host "`nAU-NE-Bristol members: $($members.Count)"

Now assign a scoped role to test the delegation boundary:

# Assign User Administrator to Phil, scoped to AU-NE-Bristol only
$phil = Get-MgUser -Filter "displayName eq 'Phil Greaves'"
$uaRole = Get-MgRoleManagementDirectoryRoleDefinition `
  -Filter "displayName eq 'User Administrator'"

$scopedAssignment = @{
  PrincipalId = $phil.Id
  RoleDefinitionId = $uaRole.Id
  DirectoryScopeId = "/administrativeUnits/$($au.Id)"
}
New-MgRoleManagementDirectoryRoleAssignment -BodyParameter $scopedAssignment

Write-Host "Assigned: Phil Greaves → User Administrator → scoped to AU-NE-Bristol"

Constraints and limitations you need to know

AUs are powerful but have specific limitations that affect governance design:

Nested AUs are not supported. You can't create an AU inside another AU. If your organization has a hierarchy (Bristol → Bristol Engineering → Bristol Engineering QA), you need separate flat AUs for each level. The AU model is flat, not hierarchical.

Adding a group to an AU doesn't add its members. This is the most common misunderstanding. If you add SG-Engineering to AU-NE-Bristol, the AU-scoped Groups Administrator can manage the group's properties and membership. But an AU-scoped User Administrator can't manage the individual users in that group unless those users are also separately added to the AU. Group membership and AU membership are independent.

AUs don't prevent browse access. An AU-scoped admin can't modify users outside their AU, but they can still see them in the directory. AUs restrict management operations — they're not visibility boundaries. If you need to prevent admins from seeing users outside their scope, the M365 admin center provides a filtered view (it hides users outside the admin's AU), but the Entra admin center and PowerShell still show all users.

Not all roles support AU scoping. Most common admin roles (User Administrator, Helpdesk Administrator, Groups Administrator, Authentication Administrator, License Administrator, Password Administrator) support AU scoping. Some roles — Global Administrator, Security Administrator, Conditional Access Administrator — don't support AU scoping because they operate on tenant-wide resources that can't be partitioned. Check the Microsoft Learn documentation for the current list of AU-compatible roles before designing your delegation model.

Licensing: AU administrators need P1 licenses. AU members don't need any license for standard AUs. Dynamic AU membership requires P1 per member. Creating AUs itself requires Privileged Role Administrator.

The delegation gap — what a flat directory means for IAM

Without AUs, the IAM program has a structural limitation: you can't implement least-privilege administration. Every admin who needs to manage users in one department must be given tenant-wide User Administrator. Every helpdesk operator who needs to reset passwords in one office must be given tenant-wide Helpdesk Administrator. The role defines the capability. Nothing constrains the scope.

The governance risk is concrete. Consider a scenario: a helpdesk operator at the Manchester office receives a social engineering call from someone claiming to be the CISO, requesting an urgent password reset. Without AUs, the helpdesk operator has the technical capability to reset the CISO's password — their Helpdesk Administrator role is tenant-wide. With a restricted AU protecting executive accounts, the reset attempt fails with an explicit error message, and the social engineering attack is blocked by architecture rather than depending on the helpdesk operator recognizing the fraud. The restricted AU doesn't require the helpdesk operator to be vigilant. It prevents the action regardless of intent.

For the IAM program specifically, the flat directory creates limitations in three downstream modules:

Module 5 (Access Reviews): Access reviews can be scoped to specific populations. But if the administrators who configure reviews have tenant-wide scope, they can create, modify, or delete any review — including reviews of their own access. AU-scoped review administrators can only configure reviews for populations within their AU.

Module 7 (Privileged Access): PIM role assignments can be scoped to AUs. Instead of making someone eligible for User Administrator across the entire tenant, you make them eligible for User Administrator scoped to the Manchester AU. They activate the role, manage Manchester users, and the role deactivates. Without AUs, PIM still works — but the scope is always tenant-wide, which limits the least-privilege value.

Module 8 (Delegation): The entire delegation architecture depends on AUs. Catalog delegation in entitlement management, scoped review administration, distributed guest management, and delegated app governance all require delegation boundaries. Without AUs, delegation defaults to "everyone manages everything" — which is the opposite of governed.

Lifecycle workflows and AU scoping: Recent additions to the Microsoft Graph API added administrationScopeTargets to lifecycle workflow resources. This means lifecycle workflows can now be scoped to specific AUs — a joiner workflow that fires only for identities in the Manchester AU, a leaver workflow scoped to contractors in the Bristol AU. Without AUs defined, this scoping capability can't be used. The AU structure you design in Module 8 directly enables the workflow scoping you configure in Module 2.

At Northgate Engineering: Rachel Okafor's delegation assessment: zero AUs, 12 role assignments all tenant-wide, Phil holding 4 permanent roles including Global Administrator. Her target architecture (Module 8): 4 AUs — Bristol HQ, Manchester, Edinburgh, Rotterdam — plus a restricted AU for executive accounts and break-glass. Phil's Global Administrator converted to PIM-eligible with approval. User Administrator for each site scoped to the site AU. Helpdesk Administrator for each site's IT contact scoped to their AU. The restricted AU protects Rachel's account, the break-glass accounts, and the high-privilege service accounts from unscoped modification. The current state: zero of this exists. The target: Module 8 builds it. The assessment: documented here, with the role assignment inventory as the baseline.

Reusable script — the delegation assessment from this section:

# IAM1.5 — Delegation and AU Assessment
Connect-MgGraph -Scopes "AdministrativeUnit.Read.All",
  "RoleManagement.Read.Directory", "Directory.Read.All"

# AU inventory
$aus = Get-MgDirectoryAdministrativeUnit -All -Property id, displayName,
  isMemberManagementRestricted, membershipType

Write-Host "=== ADMINISTRATIVE UNITS ==="
if ($aus.Count -eq 0) {
  Write-Host "None configured. Delegation model: FLAT."
} else {
  Write-Host "Total: $($aus.Count)"
  $aus | Select-Object displayName,
    @{N='Type'; E={
      if ($_.IsMemberManagementRestricted) { "Restricted" }
      elseif ($_.MembershipType -eq "Dynamic") { "Dynamic" }
      else { "Standard" }
    }} | Format-Table -AutoSize
}

# Role assignment scope
$assignments = Get-MgRoleManagementDirectoryRoleAssignment -All `
  -ExpandProperty principal, roleDefinition

$tenantWide = ($assignments | Where-Object { $_.DirectoryScopeId -eq "/" }).Count
$scoped = ($assignments | Where-Object { $_.DirectoryScopeId -ne "/" }).Count

Write-Host "`n=== ROLE ASSIGNMENT SCOPE ==="
Write-Host "Total:        $($assignments.Count)"
Write-Host "Tenant-wide:  $tenantWide"
Write-Host "AU-scoped:    $scoped"

# High-privilege permanent assignments
Write-Host "`n=== HIGH-PRIVILEGE PERMANENT ASSIGNMENTS ==="
$assignments | Where-Object {
  $_.DirectoryScopeId -eq "/" -and
  $_.RoleDefinition.DisplayName -in @("Global Administrator",
    "User Administrator", "Privileged Role Administrator",
    "Exchange Administrator", "SharePoint Administrator",
    "Authentication Administrator")
} | ForEach-Object {
  Write-Host "  $($_.Principal.AdditionalProperties.displayName) — $($_.RoleDefinition.DisplayName)"
}

Decision-point simulation

Scenario 1. NE has two offices: London (600 staff) and Manchester (210 staff). Phil Greaves wants each office's IT lead to manage users in their location without seeing the other office's users. Should you use administrative units or separate security groups?

Administrative units. Security groups control access assignment (who gets what resources). AUs control administrative delegation (who manages which directory objects). The London IT lead needs to reset passwords, update attributes, and manage group memberships for London users — without the ability to touch Manchester users. Create two AUs scoped by officeLocation, assign the IT leads scoped User Administrator roles on their respective AUs. Security groups don't provide this administrative boundary — a User Administrator without AU scoping can manage all users in the tenant.

Scenario 2. You create a restricted management AU for executive accounts (CEO, CFO, CISO, CTO). A helpdesk technician calls saying they can't reset the CFO's password. Is this the expected behavior?

Yes. Restricted management AUs remove the ability for any tenant-level administrator (except Global Administrator) to manage objects inside the AU. The helpdesk technician's User Administrator role works for all users outside the AU but is explicitly blocked for executive accounts inside it. This is by design — executive accounts should only be managed by Global Administrators or specifically scoped AU administrators. If the helpdesk needs to support executives, assign a dedicated support person a scoped role on the restricted AU with appropriate controls.

Scenario 3. Marcus Webb proposes creating 6 AUs — one per department. Rachel Okafor says that's over-engineering for a company of 810 people. Who's right?

Rachel, probably. AUs add governance overhead — each AU needs scoped role assignments, membership rules (if dynamic), and monitoring. For 810 users with a centralized IT team, 6 AUs create 6 administrative boundaries that the same 3 IT staff manage anyway. AUs are justified when different administrators manage different populations. If NE's London and Manchester offices have separate IT leads, 2 location-based AUs make sense. 6 department-based AUs make sense only if each department has its own identity administrator — which NE doesn't. Start with the minimum viable AU design and add boundaries when operational need justifies the governance cost.