I should start by saying, officially, the Microsoft docs say Identity Governance can’t manage groups in restricted Admin Units, it’s listed in the limitations.

But practically, yes, it works. Microsoft vaguely alludes to this further down the page, but if you bailed at the bit that says you can’t, you probably never read that far. So here’s the step-by-step setup.

Step 1. We need to let Entitlement Management, specifically its service principal, manage groups inside our restricted Admin Units.

To make that happen, we'll create a custom role with the required permissions, then assign that role to the EM service principal on a permanent basis.

Go to “Roles and admins”, “All roles” and then “New custom role”.

Give your new custom role a name and description that makes sense and choose to “Start from scratch” for the permissions.

On the permissions section, add the following permission, then you can “Review and create”.

Step 2. Now we are going to create a Restricted Admin Unit. You'd be surprised how many people have never heard of or noticed this Entra feature before, and if I'm being completely honest, I didn't pay that much attention to them for a while either. Whenever I'd read about them they were described in the same vein as delegated OUs in Active Directory with the old "regional IT support" model use case which does make sense I suppose.

Go to the Entra portal, “Roles and admins”, “Admin units” and then “Add”.

Give the admin unit a useful name and description and DON’T FORGET to select “Yes” for Restricted management administrative unit. Once you create an AU, you cannot go back and change this setting either way.

Click “Review+ create” and finish the creation now. If you go “Next; Assign roles” and try to assign any privileges during creation, the GUI will only allow us to select users at that point for some reason and we need to be able to see service principals.

Step 3. Now let’s permanently assign our new custom role to Entitlement Management with the scope of this new Admin Unit.

Go to your new Admin unit.

Click on “Roles and administrators” and choose the new custom role from the list.

In Assignments, click “Add assignments”

You can see on the next screen, we are assigning the “Restricted AU Groups Administrator” role with the “Scope Type” of Administrative Unit and the selected scope is our new Entitlement Management AU. If that lines up, click on “No member selected”.

In the search box enter “ec245c98-4a90-40c2-955a-88b727d97151“, you can see this will add a new column, Enterprise Applications (Service Principals) and you should see the Service Principal for Identity Governance, select this service principal.

Note the warning that applications are only allowed for active assignments, this is great as we always want Identity Governance to have these permissions. Click “Next”.

Make the assignment permeant and Input something useful for other administrators to understand why this role assignment exists and then click “Assign”.

At this point I should mention that you could also assign this role to PIM using the same method but using the service principal Id of “01fc33a7-78ba-4d2f-a4b7-768e336e890e” (MS-PIM). You could then create an AU for PIM controlled groups although managing “role assignable” groups in this way is not possible.

Step 3. All that’s left is to add groups to the admin unit. You can create new groups within the AU or you can add existing groups. (Just make sure you are happy with the current group membership when you do that - See Part 3 coming soon)

And that’s it, the only thing that can add users to a group in our AU is Entitlement Management. If another admin tries to sneak someone in because of the old classic the classic “boss says add them now”, this is what they’ll see.

Sorry mate, this request needs to go via an access package.

Technically, someone could PIM into the Restricted AU Groups Admin role in an emergency and add users. But (1) it’s audited, and (2) honestly, why? Assigning the access package is just as quick.

Coming Up Next: Part 3 - The Migration

In this post, we focused on the implementation: creating a restricted Administrative Unit, wiring up a custom role for Entitlement Management, and moving your groups inside so every membership flows through proper governance.

In Part 3, I’ll take it a step further and show you my process for onboarding existing group members into access packages - because setting up the velvet rope is one thing, but getting everyone already inside the club to leave, line up and come through the front door again, is another.

Locking it down in practice is good, migrating cleanly is even better.

Administrators have used groups to control access to resources since God was a boy. The old AGDLP (or AGUDLP, depending on how you learned it) model worked well for years and should still be second nature for managing access in on-premises Active Directory.

But the world has moved on. With the advent and evolution of Entra ID, we now have more powerful ways of managing access in the cloud. Features such as Entitlement Management, Access Packages, and Access Reviews provide capabilities that traditional AD groups never could.

There is a problem though.

When you add a group as a resource in an Access Package, there is nothing stopping a group owner or an admin with no respect for process from bypassing governance and adding users directly to that group.

And just like that, your carefully designed access package strategy is toast.

In this post, I will explain the issue; why group owners and rogue admins are a risk, and the approach I use to stop it.

In Part 2, I will walk through the technical steps to implement the solution in Entra ID.

The Problem: Backdoors to Your Process

Think about it. You have built a clean entitlement management process: requests, approvals, reviews, lifecycle management. Everything flows through clear governance controls.

But if a group owner adds a user directly, all of that work is bypassed. The access exists, and while you might catch it eventually with an access review, how long might that be?

You could also set up monitoring and alerts for changes in group membership, and if the access is particularly sensitive, you probably should. But alerts are still after the fact. By the time you are investigating, the access has already been granted, and the horse has bolted from the stable.

What we are really after is a way to stop it from happening in the first place. Prevention beats detection every time.

The Solution: Restricted Administrative Units

Here is the approach I use:

1. Create a restricted Administrative Unit (AU) in Entra ID.

2. Move the groups used in Access Packages into that AU.

3. Grant Entitlement Management the rights it needs within the AU.

What this achieves:

• Group owners and admins cannot add members behind the scenes.

• All membership changes flow through Entitlement Management.

• PIM still provides just-in-time access to manage the AU when needed.

What About Group Owners?

"Can’t group owners just add users?"

Yes, and that is part of the problem. By default, group owners can add or remove members. That bypasses your processes and makes governance meaningless.

The trick is to separate business accountability from technical control. Groups should still have owners. They are the ones who understand what the group is for, why it exists, what type of access it represents, and whether it is still needed as part of its lifecycle. They are essential for approvals, reviews, audits, and deciding when a group has outlived its purpose.

But once the groups move into a restricted AU, owners lose the ability to change membership directly. They still own the group in a business sense, but every change to membership goes through Entitlement Management. That way changes can be reviewed, tracked, audited and revoked when no longer appropriate.

That way you get the best of both worlds:

• Business accountability from owners.

• Governance and enforcement from Entitlement Management.

Bonus tip: Make the group owner the approver of the access package? That way we are still giving control to the resource owners while ensuring the governance is handled by Entra.

What About Rogue Admins?

It is not just group owners you need to worry about. In many environments, administrators have broad rights over groups by default. That means another admin could still add or remove members directly, bypassing your carefully designed access package strategy.

Restricted Administrative Units stop this as well. By moving groups into a Restricted AU and limiting who can manage them, you close off this backdoor. Regular admins lose direct control. If someone needs to make changes, they must go through PIM.

In other words:

• Day-to-day admins cannot tamper with membership.

• Elevated access must go through PIM, which adds approval, time limits, and auditing.

• Entitlement Management remains the single source of truth for access.

Why This Works

By moving those groups into a restricted AU, you are effectively putting them behind a velvet rope:

• Governance is preserved.

• Business owners are still accountable.

• Reviews stay accurate.

• And your auditors do not chase you down asking why Bob from Finance magically appeared in the "Global Admin Test" group.

It is not glamorous, but it is clean, effective, and makes sure your Access Package strategy actually works as designed.

Coming Up Next: Part 2 - The Implementation

In this post, we focused on the issue: how group owners and admins can bypass your carefully crafted access package strategy, and how restricted Administrative Units can close that backdoor.

In Part 2, I will show you the step-by-step implementation:

• How to create a restricted Administrative Unit and move your groups into it.

• How to configure PIM and Entitlement Management so you keep governance without losing flexibility.

Locking it down in theory is good, but locking it down in practice is even better.

Subscribe now