Use RBAC to supercharge your Entra Admin Units

In my earlier post, I called Restricted Administrative Units (RAU) the “real star of the show.”

• Administrative Units (AUs) scope directory objects like users, groups and clients.
• Restricted Administrative Units (RAUs) additionally protect objects from tenant-wide admins unless explicitly allowed.

Now let’s see how we can take them one step further with Role‑Based Access Control (RBAC). RBAC is a security model that assigns permissions based on a person’s role, ensuring they can only perform tasks relevant to their responsibilities.

😱 But have you ever given someone a role in Entra ID and realized they can now see far more than they should? That’s RBAC without RAUs.

As Microsoft often says: “Better together.”

RBAC in Microsoft Entra ID is the authorization framework that determines what actions a security principal (user, group, service principal, managed identity) can perform, and where those actions apply.

• Roles are predefined sets of permissions (e.g., User Administrator, Groups Administrator).
  • Can also be a custom set of permissions, I’ll get to that real soon 😉
• Assignments bind a role to a principal at a specific scope.
• Scope is the boundary within which the role’s permissions are valid. This is by default tenant-wide.

This highlights a common mistake I encounter far too often: Regardless of how minimal the privilege requirement is, the all-encompassing role of Global Admin is assigned. It’s both astonishing and alarming that this continues to happen even in 2025.

• Over‑permissioning: “We gave helpdesk rights to fix one user’s password… and they could reset the CEO’s.”
• Audit headaches: “Who can touch this account?” can take hours to answer without scoped roles.
• Compliance risk: Regulations demand least privilege and tenant‑wide roles are a red flag.

RBAC in Microsoft Entra ID includes over 120 built‑in roles designed to support the principle of least privilege and thereby giving admins only the permissions they need, and no more. For example:

• Assign the User Administrator role to manage users and groups.
• Use the Exchange Administrator role for Exchange Online management.
• Grant the Security Reader role to view security‑related reports and data.

By default, these roles apply tenant‑wide, but you can scope some of them to specific Administrative Units (AUs or RAUs) for more granular control.

Sounds great! How do I get started?

In Entra ID, navigate to “Roles & admins” and you should see all roles on the screen. Notice that some roles are marked with “PRIVILEGED“. These are roles with elevated, high‑impact permissions that can make broad or sensitive changes to your tenant, or have broad access to read sensitive permissions. Note that “Global Reader” is marked privileged because it can read almost everything in your tenant which is information an attacker can potentially exploit. This isn’t a “do‑not‑use” sign, it’s a guide to help you see which roles to delegate carefully, and to whom.

Sadly, this is where I feel Microsoft fumbles the user-friendliness of this feature. You see, from there you can click on a role to delegate it to a security principal (user, group etc.), but not all roles can be delegated to an AU/RAU. And there is no information here on this screen which roles can be delegated to an AU or not.

So if you select a role which cannot be delegated to an AU/RAU, you need to start the delegation process to see that you can’t select an Administrative Unit. Like this:

I select “AI Administrator” role (top of the list) and then “Add assignments“

And here I see the “Scope Type” is greyed-out and can’t be changed, ergo this can only be assigned tenant-wide

If I repeat the same process with a role I know can be assigned to an AU/RAU, like “User Administrator”, then the scope type can be changed between “Directory” and “Administrative Unit”.

Pro tip: Head over to the AU and delegate permissions there. On the AU/RAU, you’ll only see roles that are relevant to an AU/RAU. 😉 The steps are in my earlier post.

So now you can vastly improve your security posture by combining RAU and RBAC.

• RBAC = What you can do (permissions defined by role)
• AU/RAU = Where you can do it (scope boundary for those permissions)
• RBAC + AU/RAU = Least privilege with surgical precision and not wide-spread impact

📢 BUT WAIT! There’s more! We can take this a big step further still.

The Secret to Safer Delegation? Custom Entra Roles!

I would like to begin by sharing something that I believe is not widely known:

⚠️ Deleting a cloud‑only security group in Entra is always a hard-delete and is therefore immediately permanent! There’s no recycle bin or similar recovery method. Once it’s gone, so are its memberships.

😱 Yes, you read that correctly. Entra has a “Deleted groups” view, but it is only for M365 groups, not security groups. M365 groups can be restored after deletion, security groups can not. 😱

This makes the permission to delete security groups very dangerous to delegate. Especially since it can impact other areas in Entra where the user lacks access. Why bother sabotaging Conditional Access policies when you can just delete the groups they rely on? And it doesn’t have to be intentional, it can simply be deleted by mistake and still have disastrous consequences.

🦸Custom roles to the rescue!

The trick is to keep in mind that all roles are just a collection of permissions and it is these permissions that grants access.

First and foremost: Any and all critical security groups (for example groups used in your Conditional Access policies, Access package eligibility, device join allowlists and so on) should ALWAYS be placed in a SEPARATE Restricted AU! This step alone will block admins from accidentally delete the groups, and an attacker needs to gain Global Administrator or Privileged Role Administrator in order to remove its protection.

But these groups still needs to be managed, and here we use custom roles so people can perform changes but still can’t delete these groups. Remember, deleting these security groups is a permanent action which can potentially crash your environment completely!

1. Create the custom role for group memberships

In Entra portal, navigate to “Roles & Admin” and select “New custom role“.

Give it a Displayname and description:

Like I just wrote: All roles are just a collection of permissions. This list of permissions may seem intimidating at first, but you will soon see it is not as bad as you might think. Now in this example we want to delegate the permission to only change membership on groups. So we can search for membership in the search field and the list will automatically adapt to the search query.

And here we quickly see a permission which matches our need: “microsoft.directory/groups.security.assignedMembership/members/update“

Breaking the name down is surprisingly easy

• groups.security = Security groups (M365 groups are called “unified)
• assignedMembership = groups with assigned membership (not dynamic)
• members = targets members (not owners)
• update = updates the group membership

The list also includes a description of the permission: “Update members of Security groups of assigned membership type, excluding role-assignable groups“

This permission fits our need in this example perfectly! So we just select that and continue the wizard.

Looks great, just click “Create” in the bottom then your new custom role named “Group membership changes” is ready for use!

2. Assigning the role in an AU/RAU

Next I navigate to the AU/RAU I want to use it, and I can now see it under the “Roles and administrators” part of the AU.

From here you just click into it and select “Add assignment” and you can choose “Active” or “Eligible” (which I recommend to use it with PIM).

Summary

By combining RBAC with Restricted Administrative Units, you can enforce least privilege with surgical precision: Defining exactly what an admin can do and where they can do it. Built‑in roles give you a strong baseline, but scoping them to RAUs eliminates tenant‑wide impact.

For high‑risk scenarios like security group management, custom Entra roles let you strip out dangerous permissions (like group deletion) while still enabling necessary tasks. The result: tighter control, reduced attack surface, and compliance‑friendly delegation without sacrificing operational efficiency.

In short: RBAC without scope is blunt. RAUs without RBAC are under‑utilized. Custom roles bridge the gap and makes you use permissions like a precision tool instead of a sledgehammer. If you’re still handing out Global Admin for “just one task,” you’re doing it wrong! Build the role you need, scope it to where it’s needed, and keep your tenant locked down.