Microsoft Entra delegated administration architecture
Delegate identity operations to the right administrators, over the right users, groups, and devices, without confusing a scoped role boundary with a tenant partition or a complete Microsoft 365 security perimeter.
Design objective
An administrative unit is a container used to scope supported Microsoft Entra role permissions to selected directory objects. It can help a school, region, subsidiary, business unit, executive-support team, or device-operations team manage only the users, groups, or devices in its responsibility.
The unit does not create a separate tenant, security boundary for every Microsoft 365 service, network boundary, or automatic ownership model. A role assigned at administrative-unit scope applies to supported operations on objects in the unit; it does not automatically grant control of the administrative-unit object itself or every resource related to those members.
Inventory the exact users, groups, or devices that operations must manage. Avoid using organizational labels without a source and lifecycle.
Select the least-privileged built-in or custom role that supports the required action at administrative-unit scope.
Test allowed and denied actions from the administrator’s real portals, Graph clients, automation, and Microsoft 365 workflows.
Architecture choices
| Model | Best fit | Important boundary | Evidence |
|---|---|---|---|
| Assigned standard unit | Users, groups, and devices are added through an approved workflow. | Membership is manual or automated externally; role permissions remain limited to supported scoped operations. | Member register, requester, approver, administrator assignments, task tests, and removal evidence. |
| Dynamic user unit | A governed user attribute reliably maps the operational boundary. | Dynamic membership owns additions/removals; users require appropriate P1 coverage; groups cannot be included. | Rule, attribute authority/write control, validation samples, processing state, count history, and fallback. |
| Dynamic device unit | Device attributes define a support or management population. | Only device attributes can be referenced; user and device objects cannot be mixed in one dynamic unit. | Graph samples, join/registration state, duplicate/stale handling, validation, and device-lifecycle owner. |
| Restricted management unit | Selected executives, sensitive security groups, or devices require protection from tenant-scoped administrators. | Restriction is chosen at creation and cannot be changed; workflows can break; only explicitly scoped administrators modify protected Entra properties. | Threat model, supported object/role matrix, recovery administrators, workflow tests, alerts, audit records, and approval. |
Membership and role semantics
| Question | What to verify | Common false assumption | Control |
|---|---|---|---|
| Who is in scope? | Direct user, group-object, and device membership; overlaps; dynamic rules; disabled/stale objects. | A group’s members inherit administrative-unit membership. | Export member object IDs and types; compare them with the intended support population. |
| Who can act? | Direct or group-based scoped role assignees, activation, approval, MFA, device, location, and emergency path. | A unit owner or descriptive contact automatically has management authority. | Record role-assignment IDs, principal IDs, scope IDs, dates, approver, and authentication controls. |
| What can they do? | Exact role actions supported at administrative-unit scope in Entra portal, Graph, PowerShell, and connected workflows. | Every action in the role is scope-aware, or every Microsoft 365 admin portal honors the same boundary. | Build a positive/negative task matrix and test with a nonprivileged pilot administrator. |
| What overlaps? | Members in multiple units, multiple scoped roles, tenant-wide roles, restricted units, and inherited group assignment. | The narrowest scope overrides broader permission. Effective access is generally cumulative. | Calculate effective roles and test against an in-scope and out-of-scope control object. |
Test create, read, update, reset, add/remove member, device action, authentication-method, group, license, and recovery tasks individually.
Use control objects outside the unit and prove the scoped administrator cannot act on them through every supported interface.
Record help-desk, HR, sync, Graph, automation, Exchange, Teams, SharePoint, Intune, PIM, and governance dependencies.
Restricted management
Deployment lifecycle
Inventory roles, operators, objects, workflows, portals, APIs, licensing, governance, and existing tenant-wide privilege.
Choose standard/restricted and assigned/dynamic models; document purpose, membership, task matrix, and recovery.
Create the unit, add pilot objects, assign the minimum role, configure approval/activation, and preserve identifiers.
Test allowed tasks, denied out-of-scope tasks, automation, Microsoft 365 workflows, logging, and emergency reassignment.
Monitor membership and roles, review overlaps, attest owners, remove stale access, retest workflows, and retain evidence.
Top risks and common misconfigurations
Administrative units reduce scope only when membership, roles, interfaces, and recovery are all verified.
Teams assume every Microsoft 365 service and related object automatically honors the unit.
Adding a group scopes the group object, not the users inside it.
A broad role is scoped without testing whether a narrower role or custom role supports the task.
The same operator retains tenant-wide privilege, so the scoped assignment does not reduce effective access.
A self-writable, delayed, incomplete, or inconsistent attribute controls the support boundary.
An immutable setting breaks help-desk, governance, automation, or recovery workflows.
Only successful in-scope actions are tested; unauthorized reach remains undiscovered.
Architecture assumes every built-in role and task can be assigned at unit scope.
The last restricted-unit administrator leaves and no documented authority can restore operations.
Evidence and operations
Related ecosystem guides
Authoritative resources
No. It scopes supported Microsoft Entra role permissions to selected directory objects. It does not create a separate tenant or automatically isolate every related Microsoft 365 resource and service.
No. The group object becomes a member and enters scope; its users do not inherit administrative-unit membership simply because they belong to that group.
An assigned standard unit can contain those object types. A dynamic unit targets users or devices, not both, and dynamic membership for groups is not supported.
No. The restricted setting is selected when the unit is created and cannot be changed. Design, workflow, licensing, and recovery validation must occur before creation.
Not merely through the tenant-wide role. A Global Administrator or Privileged Role Administrator can manage the restricted unit and make an explicit scoped assignment, including to themselves, which is auditable.
Use a pilot administrator, in-scope objects, and out-of-scope control objects. Test each required and prohibited task through every real portal, API, PowerShell, automation, and related service, then preserve results.
IT Perfection Microsoft 365 identity operations
IT Perfection helps organizations in Irvine, Orange County, Los Angeles County, and Southern California design administrative units, right-size scoped roles, validate boundaries, test restricted workflows, document evidence, and preserve a practical failback path.
Created by Ali Hassani, CISO — 25+ years of IT, cybersecurity, compliance, and infrastructure experience.
This guide is for initial planning and operational guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, Microsoft licensing review, legal/compliance review, or tested change-management process.
