Azure Architecture Series #32 — Users, Groups and Administrative Units

Business Challenge

The Azure resource model taught one reflex above all others: a container passes things down. A policy assigned at a management group applies to every subscription beneath it. A role assignment at a resource group reaches every resource inside it. Posts #14 to #21 were largely about the consequences of that single property — where to attach a rule so that the right set of things inherits it, and how to reason about blast radius when they do.

Microsoft Entra ID has containers too. Groups hold users. Groups hold groups. Administrative units hold users, groups and devices. The vocabulary is so familiar that the reflex transfers automatically, and this is the post arguing that it should not.

Because in Entra, containment and inheritance are separate questions, answered separately for each container. Two of the four cannot nest at all. One nests but does not pass access down. One brings a group into scope without bringing the group's members. None of this is hidden — every rule below is a sentence in Microsoft's own documentation — but none of it is where you would look, and the failure mode is uniformly silent. Nothing errors. The delegation simply covers a different set of people than the person who built it believes.

Architecture

What each container is allowed to hold

Start here, because half the design errors are ruled out by the membership rules alone.

Both group types can be owned by users and service principals, which is worth registering now: group ownership is a delegation path that does not appear in any role assignment list, and a service principal can hold it.

The four places containment stops

This is the section worth keeping. Each of these is a direct quotation, and each contradicts the reflex Phase 1 installed.

Set that against the Azure side, where a management group tree supports six levels of depth and a policy assigned at the top is evaluated against everything beneath it. Same word, different physics. An architect who reasons about Entra delegation using the management group model will design a hierarchy that Entra will not build, and will then approximate it with a flat set of units that do not relate to each other at all.

The administrative unit, and the sentence that decides whether it works

An administrative unit restricts permissions in a role to any portion of your organization that you define — the university example in the docs is the canonical one, where each autonomous school gets IT staff who can manage their own students and no one else's. Users can be members of multiple administrative units, so the same person can sit in both "Seattle" and "Marketing".

Then comes the line that governs everything: if you assign a role to a user that is not a member of an administrative unit, the scope of the role is the entire tenant.

Read that as a default rather than a footnote. The absence of a scope is not a narrow scope or an error — it is the widest scope the directory has. Every delegation built on administrative units depends on a positive act of scoping having actually happened, and the consequence of forgetting is not a failure but a silent promotion to tenant-wide.

The one container that must be right at creation

Role-assignable groups are how you assign an Entra role to a group rather than to people one at a time. They carry more hard constraints than anything else in this post, and the constraints are the interesting part.

To create one you set isAssignableToRole to true at creation. The property is immutable. Once a group is created with this property set, it can't be changed. And you can't make an existing group a role-assignable group.

That should sound familiar. Post #20 established that a custom role's AssignableScopes is fixed at creation and caps its reach forever. This is the same class of decision in a different directory: a boolean chosen on day one that cannot be revisited, where the cost of getting it wrong is rebuilding the group and re-establishing its membership, not editing a field.

Three more constraints worth holding:

• A maximum of 500 per tenant. Another budget, alongside the 4,000 role assignments per scope from post #18. Large enough that nobody plans for it and small enough that a naive "one group per role per department" scheme will eventually meet it.
• Privileged Role Administrator to create one, and for Graph, the RoleManagement.ReadWrite.Directory permission is required to manage membership — the Group.ReadWrite.All permission won't work. An automation that manages ordinary groups will fail against these, by design.
• Soft delete with a 30-day window. When a role-assignable group is deleted, it's soft-deleted and can be restored within 30 days, and group owners can restore a deleted role-assignable group — which is itself a privilege worth noticing.

Why This Architecture Holds Up

Because the restrictions are documented threat models, not friction

Microsoft rarely explains why a restriction exists. Here it does, and the explanation is worth more than the rule:

If a group is assigned a role, any IT administrator who can manage dynamic membership groups could also indirectly manage the membership of that role. The worked example: an Exchange administrator who can modify dynamic membership groups could add themselves to the Contoso_User_Administrators group and in that way become a User Administrator.

That is the entire reason role-assignable groups cannot use dynamic membership. It generalises into a principle this series will use again: a rule that writes membership is a rule that writes privilege, and the rule has its own set of editors. Whoever can edit the rule holds, transitively, every permission the rule can grant — and that person does not appear in any list of people who hold the role.

The same reasoning produces the other protections. To prevent elevation of privilege, you must be assigned at least the Privileged Authentication Administrator role to change the credentials, reset MFA, or modify sensitive attributes for members and owners of a role-assignable group. Otherwise the path is simpler still: do not join the group, just reset the password of someone already in it.

Because the AU containment rule quietly decides your delegation model

Return to the rule that a group in an administrative unit brings the group but not its members, and follow it through to a design.

A regional helpdesk needs to reset passwords for staff in their region. The instinct is to put the region's group into the region's administrative unit and scope Helpdesk Administrator there. It will not work, and it will not say so: the documented table is explicit that a User Administrator scoped to an AU containing a group cannot manage the user properties of members, cannot manage their authentication methods, and cannot reset their passwords. To get those, the group members (users) must be added directly as members of the administrative unit.

So the administrative unit must be populated with users, not with the group that happens to describe them. Which raises the maintenance question immediately — and the answer shapes the whole design:

• Users and devices can be added to an AU by rules for dynamic membership, in Graph, PowerShell and the Entra admin center.
• Groups cannot. Add or remove groups dynamically based on rules is unsupported in every interface the documentation lists.
• And dynamic AU membership has a licence consequence from post #31: it moves every member of that unit from Free to P1.

Three facts that together settle the design. Populate administrative units with users; automate that population with dynamic rules; and price it as P1 per member rather than Free, because choosing the automation is what changes the bill.

Because some of these objects are not yours to manage at all

A structural constraint that predates any design you might draw: groups synced from on-premises Active Directory can only be managed on-premises, and distribution lists and mail-enabled security groups can only be managed in the Exchange admin center or the Microsoft 365 admin center. Relatedly, assigning Entra roles to on-premises groups is listed among the scenarios that aren't supported.

In a hybrid estate this is the first question to ask of any group, not the last: where does this object's authority live? A delegation design that routes through a synced group is a design whose control plane is somewhere else, and whose changes arrive on someone else's schedule.

Because standing membership is a choice, and PIM is the alternative

One line keeps the door open to the better pattern: if you don't want members of the group to have standing access to a role, you can use Privileged Identity Management to make a group eligible for a role assignment, and then each member of the group is then eligible to activate the role assignment for a fixed time duration.

Worth pricing honestly, given post #31. Role-assignable groups need P1; PIM for just-in-time activation needs P2. So "the group exists but holds nothing until activated" is a P2 design, and an estate on P1 has role-assignable groups whose members simply hold the role. That is a licensing decision presenting as a security one — and knowing which it is stops the conversation going in circles.

Key Architecture Decisions

Closing Thought

The through-line of this post is a single word doing two different jobs. In Azure Resource Manager, "container" means inheritance: put a thing inside another thing and the rules flow down. In Entra ID, "container" means membership, and whether anything flows is a separate question answered case by case — sometimes yes, often partially, twice not at all.

What makes that expensive is not the complexity; it is that the two models share their vocabulary and their portal. Nothing in the experience of creating an administrative unit signals that it will never nest, or that the group you just added brought its name and not its people. You find out when a helpdesk ticket cannot be completed, or, worse, when one is completed by someone whose scope was wider than the design said.

So the practical discipline for this phase is narrower than "understand the objects". It is: for every container you place something into, find the sentence that says what does and does not come with it. All four sentences in this post exist, all four are short, and not one of them is where you would have gone looking.

Official Azure Reference

• Learn about groups, group membership, and access
• Administrative units in Microsoft Entra ID
• Use Microsoft Entra groups to manage role assignments
• How to manage groups
• Create or update a dynamic membership group