Entra ID administrative units: delegate by entity or country without tenant-wide roles
In multi-entity or multi-country organisations, local support teams need to reset passwords and manage groups. All too often they are given a role that applies to the whole tenant. Administrative units offer a far more controlled alternative.
The principle
An administrative unit (AU) is a logical container for users, groups and devices. Roles can be assigned with a scope limited to that container: a Belgian support administrator, for example, can reset passwords only for users in the "Belgium" AU. Administrators with AU-scoped assignments need an Entra ID P1 licence.
Which roles apply
Only some roles can be scoped to an AU. Among the most commonly used:
- Helpdesk Administrator and User Administrator;
- Groups Administrator;
- Authentication Administrator;
- License Administrator;
- Cloud Device Administrator.
Check the current list in Microsoft's documentation: it changes over time, and a role not on the list can only be assigned tenant-wide.
Populating the units
Membership can be assigned manually or through a dynamic rule, for instance on the country or company attribute. A dynamic rule ensures every new starter automatically lands in the right AU, provided the source attribute is reliable and controlled.
A classic trap. Adding a group to an AU does not place its members in the AU. The delegated administrator can manage the group itself (name, membership) but not the accounts it contains, unless those are added to the AU separately.
Restricted management administrative units
A restricted management AU goes further: the objects it contains can only be modified by administrators whose role is scoped to that AU. Even a tenant-wide User Administrator or Global Administrator cannot modify them directly. This is useful to protect sensitive accounts (executives, emergency accounts, critical service accounts) from helpdesk staff with broad rights. A Global Administrator could still assign themselves a role on the AU: the feature reduces mistakes and abuse, it does not replace monitoring of the highest roles.
Limits to keep in mind
- AUs cannot be nested: no entity, country, site hierarchy.
- AU-scoped roles cannot act on accounts that hold higher administrative roles.
- Applications, Conditional Access policies and tenant settings remain outside the scope of AUs.
- A poorly written dynamic rule can pull in unwanted accounts, including guests.
Where to start
Identify the tenant-wide role assignments granted to local support or subsidiary teams. For each one, decide whether an AU with the same role would be enough. Create AUs based on a reliable attribute, test with a pilot entity, then gradually replace tenant-wide assignments. Finally, move your most sensitive accounts into a restricted management AU.