Azure AD makes it relatively easy to manage RBAC (Role Based Access Control) for the users in Azure using security groups, and Administrative Units. As with many things in Azure and Enterprise Microsoft, it's not always easy to wrap your head around how it functions. Thankfully, as with everything else in life, once you understand it, it can be difficult to really understand what was hard to know about it in the first place...

In this article, I will try to explain administrative units, the different types of security groups, and how they can be used to manage Roles for users in Azure AD.

Just like Azure AD is not like AD, security groups in Azure AD are in many ways very unlike security groups in on-prem Active Directory. Azure AD has two main types of security groups. Groups that can be assigned roles, and groups that can't be assigned roles.

Groups that cannot be assigned roles are used to apply licenses to users. Users can be added to this type of group manually or automatically based on user conditions or device conditions.

To manage user roles with groups in Azure AD, you have to first create a group that can be assigned roles. Then add roles to that group. When users are manually added to the group they will inherit roles assigned to the group.

It's important to note that groups cannot be changed to support or not support role assignments after they have been created.

Below is a proof of concept showing a role inherited from a group that supports role assignments.

Administrative Units (AUs) are used to give users the ability to manage a selected number of users and groups. If a user in the AU has an Azure AD Premium P1 or P2 license, that user can be given the role of an "administrative unit administrator". That user has full admin privileges on users that are members of the AU. By having this permission they will be able to do all administrative tasks, such as resetting passwords.

AUs can be practical for large organizations that have branch offices where they want a local Azure admin to manage users that belong to that branch office.

The AU administrator can also manage groups added to the AU. This means they can add users to the group and add roles to the group. But they cannot manage users that belong to that group.

This is a security feature that prevents AU admins from performing privilege escalation attacks by adding a user that has the Global Administrator role into a group they manage, then resetting the password on the user and signing in as that user, and exploiting the god-like privileges given to that user.