2.3 Administrative Units

The problem administrative units solve

A single Microsoft Entra tenant often serves many business units, countries, and schools. If every helpdesk technician receives tenant-wide User Administrator, they can manage every user in the company—including executives in other regions. That violates least privilege and complicates audit.

Administrative units (AUs) are containers for users, groups, and devices that enable scoped role assignments. You still use familiar Entra roles (User Administrator, Helpdesk Administrator, Groups Administrator, and many others that support AU scope), but the assignment applies only to directory objects that are members of the target AU.

SC-300 prefers AUs over "create another tenant" for ordinary delegation inside one organization.

When to recommend administrative units

Recommend AUs when all of the following are true (or when the exam stem strongly implies them):

1. One tenant should remain the identity boundary for collaboration and licensing.
2. Different teams must administer disjoint sets of identities (by country, brand, school campus, hospital ward, franchise, etc.).
3. Central IT still needs occasional tenant-wide control.
4. The required admin tasks map to Entra roles that support administrative unit scope.

Do not recommend AUs as the answer when the real need is:

• Azure resource isolation → management groups, subscriptions, resource groups, Azure RBAC.
• Application access → groups, entitlement management, Conditional Access.
• Temporary elevation alone → PIM without any population split.
• Guest lifecycle for partners → external identities / entitlement management (AUs can still hold guests, but B2B policy is the primary design).

Classic SC-300 scenario shapes

• "Contoso has helpdesks in France and Germany. Each must reset passwords only for local employees." → AU per country + Helpdesk/User Administrator scoped to that AU.
• "The university registrar may manage student accounts but not faculty." → Student AU + scoped role; faculty in another AU or default directory without that scoped assignment.
• "A subsidiary was acquired and keeps local IT for user management." → Subsidiary AU, not a second tenant, unless regulatory isolation demands otherwise.

Configure and manage administrative units

High-level lifecycle:

1. Create an administrative unit (Microsoft Entra admin center → Roles & admins → Admin units, or Microsoft Graph administrativeUnits).
2. Add members: users, groups, and/or devices depending on what you will delegate. Membership can be assigned manually or, where supported, dynamically (dynamic membership rules for AUs require appropriate licensing and configuration—exam items often use assigned membership for clarity).
3. Assign roles at AU scope: choose role, choose principal (user or group), choose the administrative unit as scope.
4. Operate: scoped admins manage only in-scope objects; verify with test accounts.
5. Review: access reviews / periodic membership audits for AU population and scoped role holders.

Membership design tips

• Prefer one primary AU dimension (geography or department) to avoid unmanageable intersections; if you need two dimensions, document which role uses which AU set.
• Putting a group in an AU does not automatically put all group members in the AU for every behavior—understand whether the scenario scopes management of the group object itself versus user objects. Many password-reset scenarios require the user objects to be AU members.
• Devices in AUs support device-admin delegation patterns where roles support device scope.

Scoped role assignments deep dive

A scoped assignment is the triple:

Principal + Role definition + Administrative unit scope

Compare with tenant-wide:

Principal + Role definition + Directory (tenant) scope

Implications:

• A User Administrator scoped to AU-West can reset passwords for users in AU-West.
• The same person cannot reset passwords for users only in AU-East unless also assigned there or holding a tenant-wide role.
• Built-in limits still apply: scoped admins generally cannot escalate into managing Global Administrators just because those admins were mistakenly added to an AU—protected admin relationships and role rules still matter. Exam items emphasize population scoping, not breaking Microsoft's privileged user protections.

Not every Entra role supports AU scope. Privileged, tenant-configuration roles (for example, many policy-wide roles such as certain Conditional Access tenant settings) remain tenant-scoped by design. If the task is "edit a tenant-wide Conditional Access policy," AU-scoped User Administrator is the wrong tool—you need a role that can manage CA at tenant scope.

Restricted management administrative units

Restricted management administrative units (also discussed as restricted management AUs / protected AUs in learning materials) add a stronger boundary: objects in the AU are manageable only by admins explicitly allowed to manage that restricted AU, blocking many tenant-wide helpdesk-style operations that would otherwise apply.

Use restricted management AUs when:

• A population is high value (C-suite, key signing officers, highly regulated staff).
• You must prevent ordinary tenant-wide User Administrators from changing those accounts.
• Central privileged admins still need a controlled path to manage them.

Exam cue words: "must not be manageable by the corporate helpdesk even though helpdesk has User Administrator," "protect executive accounts," "only the identity security team may modify these users." That points to restricted management AU patterns rather than a simple department AU alone.

AU versus whole-tenant role assignment scenarios

Worked comparisons you should be able to recreate under time pressure:

Scenario A — Central only
A 200-person startup with one IT admin.
Design: Tenant-wide roles (preferably PIM-eligible). AUs add little value.

Scenario B — Regional helpdesk
Four regions, each with L1 support.
Design: AU per region; Helpdesk Administrator or User Administrator scoped per AU; central identity team keeps Privileged Role Administrator / Global Reader / tenant Conditional Access roles.

Scenario C — VIP protection
Regional AUs exist, but executives still get password resets from local helpdesk by mistake.
Design: Move executives into a restricted management AU; assign management only to a tier-0 identity team; keep regional AUs for everyone else.

Scenario D — Wrong abstraction
"Developers need Contributor on the production subscription."
Design: Azure RBAC on the subscription/resource group—not an Entra administrative unit.

Scenario E — App access only
"Contractors need access to an app for 30 days."
Design: Entitlement management access package / groups / Conditional Access—not AU-scoped User Administrator (unless contractors' account administration is also delegated).

Implementation checklist for labs and exam recall

1. Confirm the delegation boundary (who administers whom).
2. Create AUs that match that boundary.
3. Populate user (and group/device) membership correctly.
4. Assign the least privileged Entra role that supports AU scope.
5. Test with a scoped admin account: success in-AU, failure out-of-AU.
6. Protect AU membership changes and scoped role assignments with monitoring, PIM, and reviews.
7. For sensitive populations, evaluate restricted management AUs.
8. Document that AUs scope directory administration, not Azure resource RBAC and not app SSO by themselves.

Common traps

• Using AUs to replace Conditional Access location or device controls.
• Assigning tenant-wide User Administrator and expecting AU membership alone to block access—it will not; the role assignment scope must be AU-scoped.
• Forgetting to add users to the AU, then wondering why scoped admins cannot see them.
• Confusing management groups (Azure hierarchy) with administrative units (Entra directory containers).
• Assuming every privileged role can be AU-scoped—validate role support.

Administrative units are one of the cleanest least-privilege tools in Microsoft Entra ID. On SC-300, whenever the stem emphasizes delegated administration of a subset of identities inside one tenant, start your answer with administrative units and scoped roles, then layer restricted management only when the population needs extra protection.