This chapter covers Administrative Units in Microsoft Entra ID (formerly Azure Active Directory), a critical feature for delegating administrative permissions to a subset of users, groups, or devices. For the AZ-104 exam, this topic appears in the 'Manage identities and governance' domain (15–20% of exam) and is frequently tested in scenario-based questions about delegated administration. Understanding administrative units is essential for implementing least-privilege access in large organizations.
Jump to a section
Imagine a large retail chain with hundreds of stores. The CEO (Global Administrator) can do anything in every store. However, for day-to-day operations, the company assigns regional managers who can only manage stores in their assigned region. The company creates 'regions' (administrative units) — for example, 'North America' and 'Europe'. Each region contains a set of stores (users, groups, devices). A regional manager for North America can reset passwords for employees in North American stores, but cannot even see the European stores. The CEO can delegate specific permissions to each manager — for instance, only password reset and account enable/disable. The manager never gets full control over the entire company. This mirrors how Azure AD administrative units allow you to scope administrative permissions to a subset of users, groups, or devices. Just as regional managers cannot accidentally (or maliciously) affect stores outside their region, delegated administrators in an administrative unit can only affect the members of that unit. The CEO retains ultimate control, but operational tasks are distributed safely and efficiently.
What Are Administrative Units and Why Do They Exist?
Administrative units (AUs) are containers in Entra ID that allow you to restrict administrative permissions to a specific subset of directory objects. They exist to solve the problem of 'all or nothing' delegation. Without AUs, if you grant a user the User Administrator role, they can manage all users in the tenant. In large organizations with thousands of users across multiple business units or geographies, this violates the principle of least privilege. AUs enable you to say: 'This helpdesk agent can reset passwords only for users in the Sales department, not for users in Engineering.'
How Administrative Units Work Internally
When you assign a role scoped to an administrative unit, Entra ID evaluates two things: (1) the role permissions (e.g., User Administrator can reset passwords) and (2) the AU membership of the target object. The delegated administrator can only perform the role's actions on objects that are members of the AU. The AU itself is a container that holds users, groups, and devices. It does NOT hold other AUs (they are flat).
When a delegated administrator attempts an operation, Entra ID performs an access check: Is the user assigned a role scoped to this AU? If yes, is the target object a member of that AU? If both are true, the operation is allowed. Otherwise, it is denied. This check happens at the authorization layer, before any directory write operation.
Key Components, Values, Defaults, and Timers
Administrative Unit: A container object in Entra ID. It has a display name, description, and a unique object ID.
Members: Users, groups, or devices can be members of an AU. Membership is explicit — you add or remove members individually or in bulk.
Scoped Role Assignment: You assign a built-in or custom role to a user or group, scoped to one or more AUs. The assignment includes the role definition ID, the principal ID (user/group), and the scope (AU object ID).
Built-in Roles That Support AUs: Not all roles can be scoped to AUs. The roles that support AU scoping include: User Administrator, Groups Administrator, Password Administrator, Helpdesk Administrator, Authentication Administrator, and several others. Global Administrator and Privileged Role Administrator cannot be scoped — they always have tenant-wide scope.
Default: By default, no AUs exist. You must create them explicitly.
Limits: A single tenant can have up to 300 AUs. Each AU can have up to 100,000 members (total of users, groups, and devices). A user or group can be a member of up to 200 AUs.
Propagation: Changes to AU membership take effect immediately (no replication delay).
Configuration and Verification Commands
You can manage AUs using the Azure portal, Microsoft Graph API, or PowerShell (Microsoft Graph PowerShell SDK).
Creating an AU (PowerShell):
Connect-MgGraph -Scopes "AdministrativeUnit.ReadWrite.All"
New-MgAdministrativeUnit -DisplayName "Sales Department" -Description "All Sales users and groups"Adding members (PowerShell):
$au = Get-MgAdministrativeUnit -Filter "DisplayName eq 'Sales Department'"
$user = Get-MgUser -Filter "UserPrincipalName eq 'john.smith@contoso.com'"
New-MgAdministrativeUnitMember -AdministrativeUnitId $au.Id -DirectoryObjectId $user.IdAssigning a role scoped to an AU (PowerShell):
$role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "DisplayName eq 'User Administrator'"
$au = Get-MgAdministrativeUnit -Filter "DisplayName eq 'Sales Department'"
$user = Get-MgUser -Filter "UserPrincipalName eq 'helpdesk@contoso.com'"
New-MgRoleManagementDirectoryRoleAssignment -PrincipalId $user.Id -RoleDefinitionId $role.Id -DirectoryScopeId $au.IdVerification:
- In portal: Azure AD > Administrative units > select AU > Assigned roles.
- PowerShell: Get-MgRoleManagementDirectoryRoleAssignment -Filter "DirectoryScopeId eq '$($au.Id)'"
Interaction with Related Technologies
Dynamic Groups vs AUs: Dynamic groups automatically include members based on rules (e.g., department = Sales). AUs require explicit membership. You can use dynamic groups to populate AUs by using a script that reads dynamic group membership and adds those members to an AU, but there is no native dynamic AU.
Conditional Access: AUs are not directly used in Conditional Access policies. Conditional Access scopes to users/groups, not AUs.
PIM (Privileged Identity Management): You can combine PIM with AUs to provide just-in-time access scoped to an AU. For example, a user can activate the User Administrator role scoped to the Sales AU for a limited time.
Entitlement Management: Access packages can include AUs as a resource scope, but the AU itself is not a resource; it is a scope for role assignments.
Identify Delegation Requirements
Before creating AUs, analyze your organization's structure. Determine which groups of users, groups, or devices need separate administrative control. For example, you might have regional IT teams that should only manage users in their region. Document the boundaries: each AU will correspond to a business unit, geography, or project. This step is crucial because AUs require explicit membership — you cannot easily reorganize later without re-adding members.
Create Administrative Units
In the Azure portal, navigate to Azure Active Directory > Administrative units > New. Provide a display name and description. Alternatively, use PowerShell or Graph API. Each AU gets a unique object ID. Consider a naming convention like 'AU_Sales' or 'AU_EMEA'. Remember the limit of 300 AUs per tenant, so plan accordingly.
Populate Administrative Units with Members
Add users, groups, and devices as members of the AU. You can add members individually or in bulk via CSV upload. Membership is explicit — not dynamic. For large organizations, use PowerShell scripts to add members based on attributes (e.g., all users with Department = 'Sales'). Note that adding a group as a member does NOT expand the group — the group object itself is the member, not its members. If you want the group's members to be managed, you must add each user individually.
Assign Roles Scoped to Administrative Units
Select the role you want to delegate (e.g., User Administrator) and assign it to a user or group, but set the scope to one or more AUs. In the portal, go to Azure AD > Roles and administrators > select role > Add assignment > select 'Scoped to administrative units' and pick the AUs. The delegated user can now perform only the role's actions on objects within the AU. They cannot see or modify objects outside the AU.
Test and Monitor Delegated Access
Sign in as the delegated administrator and attempt to manage a user inside the AU (should succeed) and outside (should fail). Use audit logs in Azure AD to monitor activities. Check that the delegated administrator cannot elevate privileges or access tenant-wide settings. Regularly review role assignments and AU membership to ensure they remain accurate.
Scenario 1: Global Enterprise with Regional IT Teams A multinational company has IT teams in North America, Europe, and Asia. Each team needs to reset passwords and manage groups for users in their region only. The company creates three AUs: 'NA', 'EU', 'ASIA'. Each AU contains all users and groups from that region. The Helpdesk Administrator role is assigned to the regional IT team members, scoped to their respective AU. This prevents the NA team from accidentally modifying EU users. In production, this setup handles 50,000+ users across 300 AUs. The main challenge is keeping AU membership in sync with HR data — a script runs daily to add/remove users based on their department attribute. When misconfigured (e.g., a user is missing from the AU), the delegated admin cannot manage that user, leading to support tickets. The fix is to audit membership regularly.
Scenario 2: University with Separate Faculties A university has faculties like Engineering, Arts, and Medicine. Each faculty has its own IT support staff who should manage only their faculty's users and groups. Administrative units are created per faculty. The Password Administrator role is scoped to each AU. Additionally, the Groups Administrator role is scoped so that faculty IT can create and manage groups within their AU. This allows self-service within boundaries. A common pitfall is that the faculty IT cannot manage users in cross-faculty projects — those users must be added to both AUs or a separate AU created for the project. Performance is not an issue even with 10,000 members per AU.
Scenario 3: Managed Service Provider (MSP) An MSP manages multiple customers, each with their own tenant. Within each customer tenant, the MSP uses AUs to delegate management of different departments. However, AUs are tenant-scoped — they cannot span tenants. The MSP must use separate tenants for each customer. Misconfiguration often occurs when a delegated admin is accidentally assigned a role with tenant-wide scope (e.g., Global Administrator) instead of AU-scoped — this grants them access to all users. The fix is to use PIM with AU scoping to enforce least privilege.
The AZ-104 exam tests Administrative Units under objective 'Manage identities and governance' (1.1). Expect 2-3 questions on this topic. Common wrong answers and traps:
'Administrative units support dynamic membership based on rules' — This is FALSE. Many candidates confuse AUs with dynamic groups. AUs require explicit membership. There is no dynamic AU rule.
'Any role can be scoped to an administrative unit' — FALSE. Only specific built-in roles support AU scoping. Global Administrator, Privileged Role Administrator, and some others cannot be scoped. Candidates often choose the wrong role in a scenario.
'Assigning a role scoped to an AU allows the admin to manage all users in the AU, including adding new users to the AU' — PARTIALLY TRUE. The admin can manage existing members but cannot add new members to the AU unless they have the appropriate permissions (e.g., User Administrator can create users but they are not automatically added to the AU). Adding members to the AU requires a role with directory scope write permissions, which is often not delegated.
'Administrative units can contain other administrative units' — FALSE. AUs are flat containers; they cannot be nested. Candidates may think of OUs in on-prem AD, but AUs are different.
Key numbers to memorize:
Maximum 300 AUs per tenant
Maximum 100,000 members per AU
Maximum 200 AUs per member (user/group/device)
Roles that support AU scoping: User Admin, Groups Admin, Password Admin, Helpdesk Admin, Authentication Admin, etc. (not Global Admin)
Edge cases:
If a user is a member of multiple AUs, a delegated admin with a role scoped to one AU cannot manage that user in another AU unless they also have scope on the other AU.
Deleting an AU removes all role assignments scoped to it — this can break delegated administration.
Adding a group as a member of an AU does not grant management of the group's members — only the group object itself.
How to eliminate wrong answers: Focus on the scope. If the question says 'delegate management of only Sales users', the correct answer will involve creating an AU for Sales and assigning a role scoped to that AU. Any answer that mentions tenant-wide roles or dynamic membership is wrong.
Administrative units restrict administrative permissions to a subset of directory objects (users, groups, devices).
Membership in an AU is explicit — not dynamic. You must manually add or remove members.
Only specific built-in roles can be scoped to an AU; Global Administrator cannot be scoped.
Maximum 300 AUs per tenant, 100,000 members per AU, 200 AUs per member.
AUs are flat — they cannot contain other AUs.
Adding a group as a member does NOT include its individual members; only the group object is managed.
Use PowerShell or Graph API for bulk membership management and automation.
Audit logs track all operations performed by AU-scoped administrators.
Combine with PIM for just-in-time, AU-scoped role activation.
AUs are tenant-scoped; they cannot span multiple tenants.
These come up on the exam all the time. Here's how to tell them apart.
Administrative Units
Flat container, no nesting
Explicit membership only
Used to scope Azure AD role assignments
Maximum 300 per tenant
Cannot apply Group Policy
Organizational Units (on-prem AD)
Hierarchical, nested structure
Can use dynamic membership via Group Policy
Used to apply Group Policy and delegate admin authority
No hard limit (limited by domain size)
Group Policy can be linked to OUs
Mistake
Administrative units support dynamic membership rules like dynamic groups.
Correct
Administrative units require explicit membership. There is no rule-based dynamic membership. You must manually add or remove members, or use PowerShell scripts to sync from dynamic groups.
Mistake
Any Azure AD role can be scoped to an administrative unit.
Correct
Only specific built-in roles support administrative unit scoping. Global Administrator, Privileged Role Administrator, and others cannot be scoped. The list includes User Administrator, Groups Administrator, Password Administrator, Helpdesk Administrator, Authentication Administrator, and a few more.
Mistake
Administrative units can be nested like on-premises organizational units.
Correct
Administrative units are flat containers. They cannot contain other administrative units. This is a key difference from on-prem AD OUs.
Mistake
Adding a group to an administrative unit grants delegated admins management of the group's members.
Correct
Only the group object itself becomes a member of the AU. The group's individual members are not automatically added. To manage the members, you must add each user individually to the AU.
Mistake
A delegated admin with a role scoped to an AU can add new users to that AU.
Correct
The delegated admin can manage existing members (e.g., reset passwords) but typically cannot add new members to the AU unless they have a role with directory write permissions (e.g., User Administrator can create users, but the new user is not automatically added to the AU). Adding members to the AU requires a separate permission (e.g., 'Administrative Unit.ReadWrite.All').
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, administrative units do not support dynamic membership rules. You cannot create a rule like 'all users with Department = Sales' to automatically add them to an AU. However, you can use a script (e.g., PowerShell) that reads the dynamic group membership periodically and adds those members to the AU. This is a manual or automated workaround, not a native feature.
The roles that support AU scoping include: User Administrator, Groups Administrator, Password Administrator, Helpdesk Administrator, Authentication Administrator, Identity Governance Administrator, and several others. Roles that cannot be scoped include Global Administrator, Privileged Role Administrator, and any role that grants tenant-wide management. Always check the official documentation for the complete list.
Yes, when assigning a role, you can select multiple administrative units as the scope. The delegated administrator will have the role's permissions on all objects that are members of any of those AUs. This is useful if a team manages multiple departments.
Deleting an AU removes all role assignments that were scoped to that AU. The members (users, groups, devices) are not deleted — they remain in the directory but are no longer managed by those delegated admins. Any delegated administrator who had a role scoped to the deleted AU will lose access to those objects. This can cause operational disruptions, so be cautious.
Yes, administrative units can contain devices (Windows 10/11, iOS, Android, etc.) in addition to users and groups. This allows you to delegate device management tasks, such as resetting BitLocker keys or managing device settings, to specific IT teams.
Use the Azure AD audit logs. Go to Azure Active Directory > Audit logs. Filter by 'Initiated by' to see actions by the delegated admin. You can also view the 'Target' to see which objects were affected. Audit logs capture all directory operations, including those performed under AU scope.
Yes, you can configure PIM role assignments to be scoped to an administrative unit. This allows users to activate a role (e.g., User Administrator) for a limited time, with permissions restricted to the AU. This combines just-in-time access with least-privilege scoping.
You've just covered Administrative Units in Entra — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?