7.3 Managing Delegation with Administrative Units

Managing Delegation with Administrative Units

Administrative Units (AUs) in Microsoft Entra ID are containers that restrict the scope of a role's authority to a specific subset of users and groups. They are the primary mechanism for delegated administration — letting a regional or departmental IT team manage only their own users without granting tenant-wide rights.

What an Administrative Unit Is

An AU is an Entra ID object that groups users, groups, or devices for scoping purposes only. It is not a security principal and not a license container; its sole job is to limit the scope of an Entra role assignment. When you assign a role such as User Administrator and scope it to an AU, the assignee can manage only the users and groups that are members of that AU — they cannot see or manage users in other AUs or users that are not in any AU.

Creating AUs and Adding Members

AUs are created in the Entra admin center (Identity → Administrative units) or via Microsoft Graph (/administrativeUnits). After creating an AU you add members — users, groups, or devices. AU membership comes in two flavors:

• Assigned membership — you manually add users or groups to the AU. Simple, predictable, and the default.
• Dynamic membership — you configure rules (e.g., department eq "EMEA" or usageLocation eq "US") and Entra populates the AU automatically based on user attributes. Dynamic user AUs require an Entra ID P1 or P2 license.

Dynamic membership is valuable when your organization's structure changes frequently or when user attributes reliably identify the delegation boundary; assigned membership is simpler and avoids the licensing requirement.

Scoped Role Assignments

Once an AU has members, you assign a role scoped to that AU. In the Entra admin center this is done from the AU's Roles blade; via Microsoft Graph it is a role assignment with administrativeUnitId in the scope. Supported roles include User Administrator, Helpdesk Administrator, Authentication Administrator, Groups Administrator, License Administrator, and several others — but not every Entra role can be scoped to an AU. Roles whose scope is inherently tenant-wide (e.g., Global Administrator, Privileged Role Administrator) cannot be AU-scoped.

A single user can hold the same role at different scopes: User Administrator scoped to AU "NorthAmerica" and User Administrator scoped to AU "EMEA" are two separate assignments, and the user can manage only members of the respective AU under each assignment.

Limits of Administrative Units

AUs scope the management of users, groups, and devices — they do not scope workload objects like Exchange mailbox policies, SharePoint site collections, or Teams tenant settings. If you grant a regional admin the Exchange Administrator role scoped to an AU, the Exchange Administrator role is not AU-scoped in the Exchange admin center; the admin would still have tenant-wide Exchange rights. To delegate workload admin scoped to a region, use workload-native scoping (Exchange management scopes, SharePoint site admin, Teams policy packages) instead of an AU.

This is a frequent MS-102 trap: AUs scope Entra identity management, not workload administration. The roles that can be AU-scoped are identity-management roles; the workload admin roles cannot.

Practical Use Cases

• Regional IT — AU "EMEA" contains all EMEA users; a regional IT lead gets User Administrator scoped to that AU and can reset passwords, manage group membership, and assign licenses only for EMEA users.
• University campus IT — each campus gets an AU; campus admins manage their own students and faculty without tenant-wide visibility.
• Departmental admins — AU per business unit; department admins manage their own groups and user attributes.
• Helpdesk tier-1 — AU containing non-privileged users; Helpdesk Administrator scoped to the AU lets tier-1 reset passwords for end users without exposing admin accounts.

Planning Tips

• Keep AU design aligned to your delegation boundaries, not your org chart — AUs exist to scope admin rights, so design them around who should manage whom.
• Use dynamic membership when user attributes reliably identify the boundary (e.g., usageLocation or department).
• Combine AUs with PIM (covered in 7.4) so regional admins are eligible for their scoped role rather than holding it standing.
• Audit AU membership regularly — a stale AU member is a stale admin target.
• Remember that a user not in any AU is invisible to AU-scoped admins — plan your AUs so every managed user is in exactly one relevant AU.