Today’s capabilities to segregate administrative permissions in Azure AD are limited. The Azure AD has a flat structure. In the on-premises AD we know the concept of organizational units, where we can delegate permissions to and create hierarchies. One could think the implementation of Administrative Units (AU) in Azure is a similar concept of the on-premises OU. This blog post will show why the AU concept is different and why you cannot compare it to the on-premises OUs.
The Azure Administrative Units are not a new feature (available in preview since late 2014), but a recent change in the Azure Portal UI put them on the spot again.
Why using Administrative Units?
A privileged user aka the Administrator has unrestricted administrative access to all users in a tenant. The permissions cannot be scoped to only users from a certain country or department. Special VIP user groups cannot be excluded from the normal Help-Desk Administrator. Microsoft created with the concept of AU the ability to create separate administration containers and provides a logical structure for resources. It helps to reduce the scope of administrative permissions within the tenant.
Current capabilities of Administrative Units
The AU are still in preview and currently limited to users and group objects only. A user or group can be member of one or more AUs. There is no hierarchy, nesting or inheritance available. AU Membership needs to be assigned either with PowerShell, graph or via the new Portal UI. A dynamic membership, i.e. Based on department, is not available. A scheduled runbook can close this gap easily.
By adding a scoped administrative role to an AU, you can grant admin permissions restricted to this AU only. For example, you can delegate permissions to regional administrators. A helpdesk administrator can be limited to update profile information, reset passwords, and assign groups for users only in the assigned administrative unit.
Not all Azure AD privileged roles are available for use with AUs. An overview can be found here.
What is still missing for a meaningful use?
I always recommend using Privileged Identity Management (PIM) when it comes to administrative permissions. Unfortunately, there is not support for PIM along wit Administrative Units. If you make an Administrator in PIM eligible for his role, it will change the scoped assignment on an AU to a global role on all users. This renders the AU concept useless.
In the Azure Portal for administrative Azure AD roles, the permissions assigned at AU level are not visible. They are only visible in the separate overview for administrative units. His can be confusing for Administrators.
Summary
- Administrative units can be used to scope administrator permission to users and groups
- No dynamic membership possible, automation scripts need to be leveraged instead.
- A limited subset of Azure AD roles is available for AU only
- Azure AD PIM breaks the AU restrictions, only permanent role assignments can be used currently. The use of PIM and AU for an admin is currently mutually exclusive.
- Admins using AUs need to be licensed with Azure AD P1. Users do not need any special license to be member of an AU.
- Administrative Units are not hierarchical, nor can they be nested.
Cloud Identity - Modern IT 