Administrative Units Configuration and Management – SC-300 Study Guide
Why Are Administrative Units Important?
Administrative Units (AUs) in Microsoft Entra ID (formerly Azure Active Directory) are a critical concept for the SC-300 exam and for real-world identity governance. Organizations often need to delegate administrative responsibilities to specific teams without granting them tenant-wide permissions. For example, a large university may want the IT team in each department to manage only their own users and groups, not the entire directory. Administrative Units solve this problem by providing a logical container that restricts the scope of administrative permissions to a defined subset of the organization's resources.
Without Administrative Units, role assignments in Entra ID are tenant-wide by default. This means that granting someone the User Administrator role gives them permission to manage all users in the tenant. Administrative Units enable the principle of least privilege by scoping role assignments to a specific boundary.
What Are Administrative Units?
An Administrative Unit is a directory resource in Microsoft Entra ID that acts as a container for other directory resources. Currently, Administrative Units can contain:
• Users
• Groups
• Devices
Once you create an Administrative Unit and add members (users, groups, or devices), you can assign Entra ID roles scoped to that Administrative Unit. This means the administrator with the scoped role can only manage the resources within that AU—not outside of it.
Key Characteristics:
• Administrative Units do not restrict permissions that members of the AU already have. They only restrict the scope of the administrators assigned roles over that AU.
• AUs are purely an administrative scoping mechanism—they are not security boundaries in the traditional sense.
• A user or group can belong to more than one Administrative Unit.
• Administrative Units require at least a Microsoft Entra ID P1 license (formerly Azure AD Premium P1).
• Only a subset of Entra ID built-in roles can be scoped to an AU. These include roles such as User Administrator, Groups Administrator, Helpdesk Administrator, License Administrator, Password Administrator, Authentication Administrator, and a few others.
• Global Administrator and Privileged Role Administrator can manage Administrative Units regardless of scoped assignments.
How Do Administrative Units Work?
Step 1: Create an Administrative Unit
Navigate to Microsoft Entra admin center → Identity → Roles & admins → Administrative units and create a new AU. Give it a meaningful name (e.g., "Marketing Department" or "Seattle Office").
Step 2: Add Members to the AU
You can add users, groups, or devices to the AU. Membership can be managed in two ways:
• Manually (Static/Assigned): An administrator explicitly adds and removes members from the AU.
• Dynamic membership rules: You define rules based on user or device attributes (e.g., department equals "Marketing"), and membership is automatically maintained. Dynamic AUs require Microsoft Entra ID P1 licenses. Dynamic membership rules for AUs work similarly to dynamic group membership rules.
Step 3: Assign Scoped Roles
Once the AU has members, assign Entra ID roles scoped to the AU. For example, assign "User Administrator" to a specific person with the scope set to the "Marketing Department" AU. This person can now reset passwords, update profiles, and manage users only within that AU.
Step 4: Manage and Monitor
Administrators scoped to the AU will see only the resources within their AU when performing management tasks. Audit logs capture AU-related operations for compliance and monitoring.
How Administrative Units Interact with Other Features:
• Restricted Management Administrative Units: These are a special type of AU where members are protected from management by tenant-level administrators (except Global Administrators and those explicitly granted roles over the AU). This provides an additional layer of protection for sensitive accounts. When an AU is marked as restricted management, only administrators explicitly assigned a role scoped to that specific AU (plus Global Admins and Privileged Role Admins) can modify members.
• Microsoft Graph API and PowerShell: Administrative Units can be created and managed programmatically using Microsoft Graph API or the Microsoft Graph PowerShell SDK. This is useful for automation and large-scale deployments.
• Conditional Access: Administrative Units do not directly integrate with Conditional Access policies. You cannot target a Conditional Access policy at an AU—you would use groups for that.
• PIM (Privileged Identity Management): You can make AU-scoped role assignments eligible through PIM, requiring just-in-time activation.
Common Scenarios for Administrative Units:
1. Regional delegation: A multinational company creates AUs for each country and delegates user management to local IT teams.
2. Departmental delegation: A university creates AUs for each faculty, allowing departmental admins to manage their own staff and students.
3. Sensitive account protection: Using restricted management AUs to protect executive or VIP accounts from being modified by general helpdesk administrators.
4. Mergers and acquisitions: Keeping acquired company users in a separate AU managed by their own IT team during transition periods.
Roles That Can Be Scoped to Administrative Units:
Not all roles support AU scoping. The commonly tested ones include:
• Authentication Administrator
• Groups Administrator
• Helpdesk Administrator
• License Administrator
• Password Administrator
• User Administrator
Roles like Conditional Access Administrator, Security Administrator, and Global Administrator cannot be scoped to an AU. Global Admins inherently have full tenant access.
PowerShell and Graph API Commands (Conceptual):
• To create an AU: Use New-MgDirectoryAdministrativeUnit (PowerShell) or POST /administrativeUnits (Graph API).
• To add members: Use New-MgDirectoryAdministrativeUnitMember or the equivalent Graph API endpoint.
• To assign scoped roles: Use New-MgDirectoryAdministrativeUnitScopedRoleMember.
========================================
Exam Tips: Answering Questions on Administrative Units Configuration and Management
========================================
1. Understand the Core Purpose: If a question describes a need to delegate administration to a subset of users without giving tenant-wide permissions, Administrative Units are almost always the answer. Don't confuse this with groups—groups define membership for access, while AUs define scope for administration.
2. Know Licensing Requirements: Administrative Units require Microsoft Entra ID P1. Dynamic membership rules for AUs also require P1. If a question mentions a free-tier tenant, AUs may not be available.
3. Restricted Management AUs: Be prepared for questions about protecting sensitive accounts. If the scenario involves preventing tenant-level admins (like Helpdesk Admins) from modifying certain high-profile users, the answer is likely a restricted management Administrative Unit.
4. Remember What Can Be in an AU: Users, groups, and devices. Applications and service principals cannot be placed in an Administrative Unit. If a question asks about scoping application management, AUs are not the answer.
5. Role Scoping Limitations: Not every role can be scoped to an AU. If a question asks about scoping a Conditional Access Administrator or Security Administrator to an AU, recognize that this is not supported.
6. Dynamic vs. Assigned Membership: Questions may test whether you know the difference. Dynamic membership uses attribute-based rules and automates membership. Assigned (static) membership requires manual management. If a scenario describes automatic membership based on the department attribute, the answer involves dynamic membership rules on the AU.
7. Multiple AU Membership: A user or group can belong to multiple AUs. If a scenario involves a user who needs to be managed by two different regional teams, placing them in two AUs is valid.
8. AU ≠ Security Boundary: The exam may include tricky options. Remember that an AU does not prevent the member from accessing resources outside the AU. It only limits what a scoped administrator can manage.
9. Global Admin Override: Global Administrators are not restricted by AU scoping. They can manage any resource in the tenant regardless of AU boundaries. However, restricted management AUs do limit other tenant-level admins (non-Global Admin roles with tenant scope).
10. Watch for PIM Integration: If a question involves just-in-time role activation scoped to an AU, remember that PIM supports AU-scoped eligible assignments. This combines least-privilege access with time-limited activation.
11. Creation Permissions: To create an Administrative Unit, you need to be at least a Privileged Role Administrator or Global Administrator. If a question asks who can create an AU, these are the correct roles.
12. Elimination Strategy: In scenario-based questions, if you see options like "Create a custom role," "Create a security group," "Create an Administrative Unit," or "Use Conditional Access," and the scenario is specifically about delegating user management for a subset of users—choose Administrative Unit. Custom roles define what can be done; AUs define over whom it can be done. Often both are used together, but the question will usually focus on one aspect.
13. Common Distractor: Do not confuse Administrative Units with Management Groups (which are an Azure Resource Manager concept for organizing subscriptions). Administrative Units are an Entra ID concept for organizing directory objects for delegated administration.
14. Audit and Monitoring: Changes to Administrative Units are recorded in the Entra ID audit logs. If asked how to track who was added or removed from an AU, the answer is the audit log.
By mastering these concepts, you will be well-prepared to answer SC-300 exam questions on Administrative Units Configuration and Management confidently and accurately.
