Combining Administrative Units with RBAC Roles

In my previous posts, I described how Entra ID (aka Azure AD) is the heart and backbone, and discussed how RBAC roles are used to control management of a Microsoft 365 tenant across multiple workloads. Entra ID has service limitations that you should be aware of to plan accordingly. However, the set of limitations is not static! Microsoft constantly improves its services. One example is the assumption that Entra ID has no hierarchy, which is where the concept of Administrative Units comes into play.

What are Administrative Units?

We cannot create a hierarchy in Entra ID in the same manner as available for Active Directory on-premises. But that might not be a bad thing. Think about simplicity and manageability. I have always wondered how people can deal with mailboxes containing thousands of folders and a folder depth of more than 10. The same issue of complexity can apply to the hierarchy of Organization Units in Active Directory.

Administrative Units are containers that can store the following resources:

  • Users
  • Groups
  • Devices

Resources can be logically combined into Administrative Units.

The Advantages of Administrative Units

Adding resources to administrative units allows you to delegate management tasks, which can be very handy. Think about the following scenarios:

  • The user accounts for German personnel must be managed only by German administrators
  • A dedicated team must manage all mobile devices

For anything to do with Entra ID management, you should always follow the least privileged principle. In practical terms, the best way to achieve this goal is to use RBAC roles and Administrative Units together.

For example, to meet the first requirement, you grant the RBAC role User Administrator to the German administrators, but ONLY for users within the Administrative Unit containing German accounts.

The same procedure can be used to achieve the second requirement: grant the dedicated mobile management team the RBAC role Device Administrator, but only for the Administrative Unit containing mobile devices.

Combining RBAC roles and administrative units means that administrators receive privileged permissions only for the objects they need to manage. Otherwise, they would have access to all users and devices.

Creating an Administrative Unit

This topic is well documented, so I won’t cover how to create an administrative unit here. You can choose your preferred method as shown in Figure 1:

Choose how you create an Administrative Unit
Figure 1: Choose how you create an Administrative Unit

Before you start, ensure the signed-in account has a Microsoft Entra ID P1 or P2 license assigned and has the necessary permission: either Global Administrator or Privileged Role Administrator. Realistically, a Global Administrator is used. If you use either the Microsoft Graph PowerShell SDK or native Microsoft Graph, the signed-in account must hold the same role, and the app used must be assigned the [insert permission].

Maintaining Administrative Units

Creating administrative units is simple. Maintaining the units thereafter can be very challenging. The Importance of Standardizing Microsoft 365 Account Creation outlines why you should pay attention to populating the properties of newly created accounts. Automating based on user properties is a good idea. The same applies to devices and groups.

When an Administrative Unit is created, the Membership type is assigned by default unless you use Microsoft Graph (either PowerShell SDK or native) and define the property membershipType as dynamic. If you want to change the membership type after creation, you can do it via the Properties tab in the Entra admin center (Figure 2).

Switch membership type in UI
Figure 2: Switch membership type in UI

Once you switch, you must define a dynamic query (membership rule) to find the objects for the administrative unit (Figure 3). See this article for more details on using dynamic administrative units. As mentioned before, administrative units can be created with PowerShell, including dynamic administrative units.

After switching, you can define a query
Figure 3: After switching, you can define a query

In Figure 4, you can see a membership rule designed to find all mobile devices:

(device.deviceOSType -startsWith “Android”) or (device.deviceOSType -eq “iOS”)

The Dynamic membership rule builder
Figure 4: The Dynamic membership rule builder

When it comes to my first scenario, where only German accounts must be members of the Administrative Unit, you could use the property usageLocation as shown in Figure 5:

A membership rule to find German accounts
Figure 5: A membership rule to find German accounts

However, there are many ways to fill an Administrative Unit with resources. It all depends on your scenario and requirements. A tenant directory with a clear structure and accurate provisioning of user accounts makes it much easier to create dynamic administrative units.

Although you can build complex queries, I recommend keeping dynamic membership rules simple!

Adding RBAC to the Mix

With some suitable Administrative Units in place, we now need to delegate administrative permissions to meet requirements. Microsoft has published solid documentation for role assignment, so there’s no need to cover it here.

However, I want to point out that for a scoped assignment using the UI, it is crucial that you go to the property Roles and administrators of an Administrative Unit to create the assignment, as shown in Figure 6:

Search for a specific role
Figure 6: Search for a specific role

Figure 7 shows the user we want to assign the role to. In this example, I assign the role for the Administrative Unit directly to a user account. Best practice is to use Access Packages or Privileged Identity Management and to avoid direct assignments. I covered this topic in my previous article here at the end. However, if you use an Enterprise App for automation, e.g. with Azure Runbooks or a 3rd party vendor, there is no other way than direct assignment.

We assign the role User Administrator to Alex Wilber
Figure 7: We assign the role User Administrator to Alex Wilber

The Entra ID admin center reveals details of assigned roles and any scoping for user accounts, as shown in Figure 8:

Viewing the assigned role and the resource the user has access to
Figure 8: Viewing the assigned role and the resource the user has access to

Restricted Administrative Units

We should cover the topic of Restricted Administrative Units. These objects behave exactly like “regular” Administrative Units, except that only explicitly assigned roles and their members can modify the resources within the administrative unit.

In a regular Administrative Unit, a user with an unscoped User Administrator role can modify users within the unit. The same user cannot do this for users within a Restricted Administrative Unit!

This article covers how to scope high privilege permissions to manage groups in an Administrative Unit, which highlights the difference between the types of units.

Conclusion

As you can see, Microsoft Entra ID is not such a flat directory. Administrative units help to improve security by lowering the scope of high-privilege roles. I know that the use of administrative units requires Entra ID P1 or P2 licenses, but in most cases, administrators probably already have those licenses. Start your planning to use administrative units now!

About the Author

Ingo Gegenwarth

Ingo Gegenwarth is a Technical Consultant at a market-leading organization for enterprise application software. In his role, he is responsible for the Exchange infrastructure as well as Office 365. In 2003, he earned his first MCSE 2000, and since then he's earned Microsoft Certified Master (MCM) and Microsoft Certified Solutions Master (MCSM).

Leave a Reply