Microsoft Entra Restricted Management Administrative Units: Delegating Control Without Sacrificing Security
- Sebastian F. Markdanner
- Jun 9
- 8 min read
Updated: 19 hours ago
Today, I’ll take a closer look at Microsoft Entra Administrative Units (AUs) and Restricted Management Administrative Units (RMAUs)
Despite being incredibly useful, AUs and RMAUs are still underutilized in many environments. As organizations scale and responsibilities shift across teams, the need for scoped delegation becomes increasingly important. AUs let you define clear administrative boundaries, while RMAUs go a step further by blocking even high-privileged roles from managing sensitive resources — unless they’ve been explicitly granted access at the AU level.
If you’re still relying solely on global roles or loosely defined access models, it’s time to reconsider. These features not only enhance your security posture but also streamline operations and reduce the risk of accidental or unauthorized changes.
Table of Contents
What is Microsoft Entra Administrative Units?
Administrative Units (AUs) in Microsoft Entra are similar in concept to Organizational Units (OUs) in traditional on-premises Active Directory. AUs group users, devices, and groups into containers, making it easier to organize resources and scope permissions precisely.
You can add resources to an AU either by using dynamic user/device queries or by assigning them directly.
Note: If you use a dynamic query, you can only include the resource type the query targets. For example, a device-based dynamic query won’t let you manually add users or groups — and vice versa.
When you scope a role or permission to an AU, it applies only to the resources within that AU. This allows the use of highly privileged roles, but within clearly defined boundaries.
Example scenario
Let’s say a school has multiple departments and administrative teams. To reduce the IT team’s workload, responsibilities are delegated per department.
Admin A — a global-level privileged user — creates an AU for the School of Business, named AU-SoB.
Membership in this AU is defined using a dynamic query to automatically include the appropriate users, devices, and groups tied to the School of Business.
Within that department, several administrators are responsible for different tasks. Admin A assigns permissions scoped specifically to AU-SoB, ensuring each admin only has access to the resources relevant to their role.
These role assignments can be managed like any other — including through Privileged Identity Management (PIM). (For more on that, check out this blog post.)
Example scenario overview
Used with permission from Microsoft. Source: Microsoft Learn: Administrative units in Microsoft Entra ID
With these capabilities, Administrative Units provide a smart way to delegate responsibilities while keeping workloads manageable — all without compromising security or flexibility.
What is Microsoft Entra Restricted Management Administrative Units?
Restricted Management Administrative Units — or RMAUs — build on the capabilities of regular AUs by (you guessed it) restricting who can manage the resources within them.
RMAUs strip away inherited permissions from global roles, including Global Administrator and other high-privileged roles. That means even a Global Admin won’t be able to manage a resource inside an RMAU unless they’ve been explicitly granted permission at the AU scope.
Here’s what it looks like when a Global Admin tries to manage a group protected by an RMAU:
However, it’s important to note that RMAUs do not prevent Global Admins or other privileged roles from managing the RMAU itself. So, RMAUs shouldn’t be your go-to solution for fully protecting sensitive resources from malicious or compromised privileged accounts.
Instead, they’re best used as part of a layered security approach, working alongside features like Privileged Identity Management (PIM) and Authentication Contexts to build strong boundaries and control access, enforcing strict AuthN policies.
🔒 Key Detail: RMAU restrictions only apply to resources directly assigned to the AU. For example, if you assign a group to an RMAU, the group’s settings and membership are protected — but not the members of the group themselves.
Role assignments for RMAUs should be managed via PIM, and ideally combined with strict sign-in policies using Authentication Contexts to ensure secure access at every step.
How to Set Up Microsoft Entra Restricted Management Administrative Units
To create a Restricted Management Administrative Unit (RMAU), you’ll need either the Privileged Role Administrator or Global Administrator role.
Here’s how to do it:
In the Entra portal, expand the menu by selecting Show more.
Navigate to Admin units under the Roles & admins section, then click Add to start the creation wizard.
Provide a name and description for the AU, and be sure to enable the Restricted management option.
(Optional) Add permanent role assignments.
💡 I recommend assigning groups rather than individuals. These groups can then be managed through PIM.
Here’s a list of supported built-in roles that can be assigned at the AU level:
Review your settings and click Create to finish creating the RMAU.
After creation, you can switch the assignment type from Assigned to a Dynamic user or device query, depending on your use case. Then begin adding resources.
To add a resource, open the RMAU and navigate to the type of object you want to manage.
In this example, I’m adding an existing group by clicking Add. You can also create a brand new group by selecting New group.
Testing the setup, we see that even with a Global Administrator account, I’m unable to manage the group membership — which confirms the RMAU is working as expected.
Important behavior to note:
Because only the group was directly assigned to the RMAU, I can still manage the user directly.
✅ This is expected behavior. If you want to restrict management of the user object, you’ll need to assign that user directly to the RMAU.
Managing permission to RMAU with PIM
Now that we’ve got our RMAU in place, it’s time to manage who has what access and when by using Privileged Identity Management (PIM).
Assigning roles for an RMAU through PIM works just like assigning global roles — the key difference is the scope.
Instead of selecting Directory as the Scope type, choose Administrative Unit. From there, you can pick the RMAU you want to target.
Once selected, assign the role as eligible or active — just like with any other PIM role assignment — but now with scoped access, ensuring least privilege is enforced.
Known limitations of AUs and RMAUs
With great power comes a few important limitations. While Microsoft Entra Administrative Units and Restricted Management Administrative Units are highly useful, there are some boundaries and caveats worth knowing before deploying them at scale.
No AU Nesting
AUs do not support nesting.
If you use an RMAU to restrict management of a group, the restriction applies only to that group — not to any nested groups within it, and the same goes for regular AU permissions.
Not Supported in Entra ID Governance
AUs are currently not supported in most Microsoft Entra ID Governance features, including:
The exception is Privileged Identity Management, which fully supports AU-scoped role assignments.
RMAUs Only Restrict Direct Members
This point bears repeating: RMAUs only restrict the management of users, groups, or devices that are directly assigned to them.
For example, if you assign a group to an RMAU, only the group object is protected — not its members.
Dynamic queries can help automatically populate AUs with relevant users or devices, but the restriction still applies only to what’s explicitly included.
Limited Support for Custom Roles
While AUs support custom roles, these roles must include at least one permission action that applies to users, devices, or groups.
If the role doesn’t include any of those actions, it will not work when scoped to an AU.
Restricted Scenarios: Actions Blocked by RMAU Scope
Certain high-privilege actions are blocked outright when a resource is part of an RMAU. Affecting multiple scenarios where scope enforcement overrides global permissions.
For example, if a Global Administrator’s account is placed inside an RMAU, even other Global Admins or Privileged Role Administrators will be unable to reset their password unless the user is first removed from the RMAU.
This behavior applies to other sensitive operations as well, and it reinforces the need to plan AU assignments carefully — especially when dealing with privileged accounts or break-glass users.
Role-Enabled Group Restrictions
If you place a role-enabled security group into an RMAU, membership changes to that group are blocked — whether through direct assignments or PIM.
This applies regardless of the admin’s role, even when correctly scoped for the RMAU.
Role Assignment UI Glitch
When viewing role assignments within an AU, the Entra portal UI may show all active assignments of the role across the directory, regardless of scope, see screenshot.
This can be misleading when reviewing RMAU-specific assignments.
For accurate visibility, use PIM to check scope and eligible assignments instead of relying on the AU UI.
Real-world Examples of RMAUs
Now that we understand what RMAUs are and how they work, let’s look at a few real-world examples of how they can be used to secure access and delegate control.
Scenario 1: Sensitive User Management
In most organizations, some users are inherently more sensitive — think C-level executives, board members, or individuals with access to highly confidential data. These accounts need tighter controls to prevent unauthorized management actions like password resets or property changes.
In this scenario, the helpdesk team is assigned standard admin roles such as Helpdesk Administrator, Cloud Device Administrator, and User Administrator.
To prevent them from managing sensitive accounts, an RMAU is created. The users and devices needing protection are added directly, and only a few trusted administrators are assigned eligible roles at the RMAU scope through PIM.
Scenario 2: High Privileged Group Management
A mid-sized company uses persona-based groups for Conditional Access and permissions provisioning. One group includes tier 3 internal admins with access to high-privileged roles and sensitive apps. Another group is used to provide RDP access to on-premises domain controllers via Global Secure Access, with membership controlled through PIM.
To ensure these groups can’t be accidentally or maliciously modified, they are placed inside an RMAU. This locks down the groups and ensures only scoped administrators can manage them.
Scenatio 3: Role-Enabled Group Restriction
A company has a role-enabled persona group designated for break-glass accounts. These accounts are excluded from all Conditional Access policies — except a few requiring hardware security keys — and provided Global Administrator rights via group membership.
To lock this group down, it’s placed in its own RMAU. This ensures the group membership can’t be modified unless someone:
Removes the group from the RMAU,
Changes its members, and
Reassigns the group back to the RMAU.
It’s a deliberate barrier that reduces the risk of accidental or unauthorized changes.
Scenario 4: Separation of duty
In a large, multi-national enterprise, each country has its own IT team — but they all operate under a single tenant. To delegate responsibility cleanly, AUs are created per region using the following structure:
Dynamic User AU scoped by department and office location:
(user.accountEnabled -eq true) and (user.department -startsWith "something") and (user.physicalDeliveryOfficeName -in ["CityA","CityB"])Dynamic Device AU using Autopilot group tags:
(device.devicePhysicalIds -any (_ -eq "[OrderID]:<GroupTagValue>"))Assigned Group AU for each geo-specific team
For executive and high-sensitivity users, devices, and groups at each site, an RMAU is layered on top. This prevents even global admins from unintentionally managing or modifying these resources, ensuring strong separation of duties across regions.
Conclusion: Delegation Done Right – Scoping Access Without Losing Control
Administrative control in Microsoft Entra doesn’t have to be all or nothing. With Administrative Units and Restricted Management Administrative Units, you gain the ability to delegate access precisely — empowering local teams while protecting sensitive resources from accidental or unauthorized changes.
By adopting AUs and RMAUs, you reduce the blast radius of over-permissioned roles, support operational clarity, and align your identity governance model with Zero Trust principles. When combined with tools like Privileged Identity Management and Authentication Contexts, you create a layered defense that scales with your organization.
Now with that said — and to uphold tradition — here’s your bad joke of the day:
Why did the sysadmin go broke?
Because he cleared his cache! 💸😎
Whether you’re managing access by region, department, or sensitivity level, using AUs and RMAUs lets you enforce boundaries where they matter most. It’s time to move past monolithic role models and embrace scoped, secure delegation.
If you found this post useful, feel free to share it with your network or team — chances are they’ll benefit from these practices too.
You can also sign up on the website to stay updated on future posts like this, and if you’re active on LinkedIn, follow me here for regular insights on Microsoft Entra, identity security, and governance in the Microsoft Cloud.
Thanks for reading — and stay tuned for the next blog post!
Comments