Administrative units. The Azure AD sort-of equivalent of organizational units (OU’s). For those less familiar, administrative units (AU’s) allow for granular assignment of RBAC roles in Azure AD.
Organizations initially struggled with the limited ability to delegate granular RBAC roles in Azure AD, with the directories flat structure; especially for all of us coming from an Active Directory background. When administrative units were introduced, they started to open up the door for organizations that needed to delegate access to a subset of users in an Azure AD tenant.
The one catch with AU’s that was a non-starter for many organizations – they weren’t dynamic. And while OU’s are not dynamic in Active Directory, it’s a different take when the tenant is usually secondary to AD being authoritative. Move a user in AD, one would hope that the location in Azure AD would follow. While there are some PowerShell scripts out there that feel very akin to those used for AD shadow groups, overall maintenance of AU’s could prove cumbersome in dynamic organizations.
The struggle, however, is no more – administrative units now support dynamic user and device membership!
Dynamic membership for Administrative Units is currently in Public Preview in Azure AD
Administrative Unit Use Cases
Before exploring dynamic membership, I just wanted to touch on some of the use cases that have already existed, and many that can greatly improve with dynamic membership. This is just a mere tip of the iceberg for use cases – if you see ones that I’ve missed let me know and I’ll gladly add it.
While they feel similar to OU’s, the fact that AU’s are virtual units of structure, they provide much greater flexibility than OU’s. A user can belong to several AU’s, and you don’t have to worry about users being linked as child objects that are deleted if an AU is removed – everyone remembers that time that their AD backups were tested with an accidental OU deletion ?.
Regional IT Delegation
Many global organizations that operate out of a single Azure AD tenant still have localized and regional support desks. With AU’s, you can create multiple layers of support structure to provide for things like password reset and user object management, without needing to deal with the complications of trying to fit complex delegations of ACL’s onto objects the same way we would have to with Active Directory.
State and Local Government Agency Delegation
Many organizations in the public sector operate out of the same Azure AD tenant to support a single O365 environment. However, many agencies still want to retain levels of autonomy over managing their user objects. administrative units can provide for that granular level of RBAC control.
My Staff Management
My Staff came out to primarily help assist with managers performing basic tasks for front line workers. The goal is to bring the power to non-IT employees the ability to do things like reset passwords or manage phone numbers for MFA. My Staff is driven by administrative units, with AU’s that are built to replicate an organizational staffing structure. For more information on My Staff, take a look at the Microsoft documentation, Use My Staff to delegate user management – Azure AD | Microsoft Docs.
It takes a bit of work in Azure AD Connect, because the manager attribute is a reference attribute in Active Directory, to synchronize the manager UPN as a custom attribute (even though manager is synchronized by Azure AD Connect, it is not exposed as a dynamic attribute option). But one could configure a system where managers have control over their employees objects, and with dynamic membership, their manager changes in AD can easily follow them in My Staff.
Exploring Administrative Unit Dynamic Membership
If you’ve used dynamic membership for groups, the logic and expressions for dynamic administrative units is the same. I won’t deep dive into all of the rules available, but the options for evaluation are both flexible and immensely powerful. For more details on the rules, take a look at this Microsoft documentation, Rules for dynamically populated groups membership – Azure AD | Microsoft Docs.
Licensing
As with dynamic group membership, current documentation indicates that any user who is a member of an AU that is dynamically populates requires an Azure AD P1 or P2 license assigned to them. This contrasts static membership, where only those managing the AU’s require a P1 or P2 license; users can be members of the AU’s with an Azure AD free license. Dynamic device membership does not require any special license for AU’s. For more information, see the Microsoft documentation, Manage users or devices for an administrative unit with dynamic membership rules (Preview) – Azure Active Directory | Microsoft Docs.
Configuring Administrative Unit Dynamic Membership
While the expression set is the same as dynamic groups, currently you have to adjust the administrative unit to be dynamic post-creation. Also, as we go through this, I’ll be referencing the current Microsoft documentation on dynamic membership for administrative units, which can be found here, Manage users or devices for an administrative unit with dynamic membership rules (Preview) – Azure Active Directory | Microsoft Docs.
First we create a new administrative unit:
And after creation of the AU, we can go look at the Properties for it. Within here we will find Membership type, which we can drop down and select Dynamic User:
After setting the Membership type to Dynamic User, we will need to Add dynamic query before we can save the changes. The dynamic query is the secret sauce to what makes the dynamic AU, dynamic. Note that until we set this query, we cannot save these changes; the save is greyed out.
In our example here, we are going to use a rule for physicalDeliveryOfficeName equals Schenectady:
We save the rule, and now the Save button will be available on the administrative unit properties. Before saving, we will be presented with a warning:
After changing the administrative unit type, the existing membership may change based on the dynamic membership rules you provide. Click Yes to continue.
The warning here will show up, regardless of whether it’s a new, unpopulated AU, or if it’s an existing AU with thousands of users within it.
After a few minutes of churning, the AU will be populated:
Converting an Administrative Unit to Dynamic
During testing of conversion of an assigned AU to dynamic, I was curious to see how it operated. Does it wipe out all membership and start from scratch, or does Azure AD evaluate the users within the AU to determine who still belongs? Luckily, it appears to be the latter.
Checking my Azure AD Audit logs, we can see users who no longer belong in a specific administrative unit being removed:
Note that if you are going the other direction, from dynamic membership to assigned, Azure AD will indicate that the existing users in the AU will be retained, but will not be dynamically processed anymore.
Exploring with PowerShell
As with most things Azure AD, anything that can be done in the portal can be done with PowerShell (which really is just indirect Graph) and Graph.
I’ve been making a concerted effort to use the Microsoft Graph PowerShell SDK, Install the Microsoft Graph PowerShell SDK – Microsoft Graph | Microsoft Docs, over the Azure Active Directory PowerShell for Graph modules. Why? The PowerShell SDK supports PowerShell 7, is cross-platform, and provides access to all of Graph, not just Azure AD.
That being said, I’ve found the PowerShell SDK modules for dynamic administrative units to be, well, rather lacking. While there are indirect parameters to provide dynamic information, I haven’t spent the cycles yet figuring things out. The docs/get-help provide almost no information on commands like New-MGAdministrativeUnit
As such, for the purpose of getting this post published, I’ll be using the Azure AD PowerShell modules.
First, let’s take a look at the administrative unit named ATZ:
Get-AzureADMSAdministrativeUnit -Filter "DisplayName eq 'ATZ'" | fl
We can see that the membership type is dynamic, and also see the membership rule. In this case, we are using the in rule to allow for matching the country attribute against a defined list.
And if we then enumerate the membership of the AU, we can see that the logic works:
Get-AzureADAdministrativeUnitMember -ObjectId a5175ada-f6f1-4c72-a986-65c65f662bde | Get-AzureADUser | ft ObjectId,UserPrincipalName,Country
We can also create an administrative unit rather easily with PowerShell, which has an advantage, at least currently over the portal, in that we can define the dynamic rules upon creation.
New-AzureADMSAdministrativeUnit -DisplayName "US" -Description "US Employees" -MembershipType "Dynamic" -MembershipRuleProcessingState "On" -MembershipRule '(user.country -eq "United States")'
FAQ
Limitations
Microsoft does not publish a size limitation for administrative units, but the standard limitations for administrative units still exist with resources being members of no more than 30 administrative units, and an organization can have a maximum of 5,000 dynamic groups and dynamic administrative units combined. The latter bit is an interesting item to note, as it would seem the evaluation engine is then shared in a tenant between dynamic groups and administrative units (which makes sense really).
I would also then speculate, while I cannot find it published yet, that administrative units may fall into the same rule evaluation service level, which is up to 24 hours, per this document, Fix problems with dynamic group memberships – Azure AD | Microsoft Docs.
How can I test/preview a dynamic membership rule?
Currently the dynamic membership rule settings in an administrative unit does not have a rule validation option available. However, we can simply create a test dynamic group in Azure AD for evaluating the rule, and can also use the Validate Rules option to get a more instant verification of whether or not our rule works.
Can I combine different object types in a dynamic administrative unit?
Unfortunately this is one trade-off between statically assigned groups and dynamic ones. Whereas in static groups we can assign users, groups and devices to the same AU, for dynamic membership you are limited to the type of dynamic object assignment you are looking to use – either user or device. Also, groups are not an option for dynamic administrative unit rules, and can belong to neither dynamic user or dynamic device AU’s.
Final Notes
Dynamic groups are already such a powerful option for organizations, it’s great to see that same logic added into administrative units, an area where it fits so well. If I had the time I would reach out to all those customers who had the “this is great, but it’s too inflexible” mindset upon seeing administrative units. I’m curious to see what new doors this opens for organizations; if you have some interesting use cases, give me a shout.
