👮 Restricted Management Admin Units (RMAU) in #EntraID
— Merill Fernando (@merill) March 29, 2025
Hackers HATE This Hidden Entra ID Feature Most Admins Never Use@NathanMcNulty breaks it down for us 👇
🎧 Get the full podcast episode at https://t.co/gnvH23WorW pic.twitter.com/nxBwCQ6BwS
I recently had a chance to discuss Restricted Management Administrative Units (RMAUs) with Merill, and one of my favorite uses for these is to protect groups that are used in Conditional Access policies so they aren’t accidentally modified or deleted. I’m also a big fan of using Access Packages to control membership of these groups for things like exclusions from geofencing policies, user action policies, blocking policies, etc.
I’ve received great feedback from folks, but most commonly I see two complaints about RMAUs - they are still in Preview and you can’t manage groups in them with Entitlement Management. On the Preview topic, it’s a fully supported feature that provides value, and you should still use it. On the Entitlement Management note, well, we have to keep reading :)
The docs are correct that PIM and Access Packages are no longer able to manage groups once you add them to a RMAU, but they also tell us why and how to make it work. Unfortunately, they just aren’t clear enough that most would figure this out, so that’s what I will walk you through here ;)
If we read the Programmability section above, we’ll notice that applications (using the application permissions model) are restricted from managing objects in RMAUs, but we can grant them delegated permissions which allows them to work. Combine that with the fact that Entitlement management is an application with a service principal, and you can probably see where this is going.
Video walkthrough
If you’d like to skip the reading and jump right into setting this up, you can follow the video here. In the rest of this post, I’ll explain each of the steps I’m going through in this video and why we are doing things this way.
Creating a custom Entra role
The first thing we want to do is create the least privileged role that we can to allow the service principals for PIM and Entitlement Management to manage group membership. If you are interested in more details than I provide here, please see the documentation on how to Create a custom role in Microsoft Entra ID and the Group management permissions for Microsoft Entra custom roles.
In Entra, we are going to Roles & admins and creating a New custom role.
Give the new custom role a name such as Group Membership Administrator and click Next. Now we are going to search for and select microsoft.directory/groups.security.assignedMembership/members/update. With that permission selected, click Next and then click Create.
Adding groups to the RMAU
Now we are going to navigate to the Restricted Management Admin Unit where we want to protect our groups, select Groups, click Add, and add the groups used with Access Packages and/or PIM to the RMAU.
Granting roles to service principals
Next, navigate to Roles and administrators in the RMAU, search for Group, and select the custom role you created.
And finally, we are going to click Add assignments and search for the following two Service Principals and add them:
Azure AD Identity Governance - Directory Management (AppID: ec245c98-4a90-40c2-955a-88b727d97151)MS-PIM (AppID: 29eea528-113e-49f7-86db-5e09f3382051)
Note
Some older tenants may have
Azure AD Identity Governance - User Managementinstead ofAzure AD Identity Governance - Directory Management. I recommend you verify the Application ID is correct.
Conclusion
At this point, we have now protected our special groups from accidental (or malicious) modification/deletion while still allowing membership to be governed by PIM and Access Packages! If you would like some more ideas and examples of using groups governed by Access Packages, you can check out the resources I created for MMS 2024 Flamingo Edition
