Last Update: Sep 04, 2024 | Published: Oct 15, 2020
Since its launch in 1999, Active Directory has used Organizational Units (OUs) to logically partition the directory. Despite discussions going back as far as 2014, the ability to partition Azure Active Directory in the same or an equivalent manner wasn’t available. Administrative Units (AUs), launched in public preview in April 2020 and now generally available, together with scoped delegation of administrative roles, allows Microsoft 365 tenants to logically divide the management of Azure AD much like they might have done for Active Directory on-premises.
Microsoft defines an administrative unit as a container for other Azure AD resources. Currently, those resources are limited to user accounts and groups. The basic idea is that you create a set of AUs to match the administrative structure of the organization, and then delegate roles to allow people to manage the objects in the AUs.
Delegation of permissions for AUs isn’t necessary to run a well-managed Azure AD, but it’s where a lot of goodness exists because it stops having to grant accounts permissions to manage every object in Azure AD. It’s certainly understandable that the global administrator for a tenant should have the right to manage everything, but less so for someone working on a help desk who supports a limited set of people. Some organizations might use geographic regions as the basis for AUs; some might use business units. The same concept applies: each AU holds a set of objects that can be managed by people granted permissions to do so. Administrative units are an Azure AD Premium feature, so you need to assign an Azure AD Premium license to each account used to manage AUs.
So much for the theory. Let’s see how easy it is to set up AUs and use delegated management.
You’re not going to use Microsoft 365 management tools to work with AUs. Instead, you have the choice between:
According to the documentation, these tools allow a delegated administrator to manage user accounts and groups (depending on their assigned role). Because it’s good to know how to script maintenance operations which might involve hundreds or thousands of objects, let’s cover the basics of how to create and populate a new AU with PowerShell. Bulk import of accounts from a CSV file is also supported, but once you’ve mastered the necessary cmdlets, PowerShell offers more flexibility.
To begin, I created a new Administrative Unit by running the New-AzureADMSAdministrativeUnit cmdlet:
New-AzureADMSAdministrativeUnit -Description "Ireland Region" -DisplayName "Ireland" Id OdataType Description DisplayName -- --------- ----------- ----------- 0ee53a45-bbee-4571-a407-56acc0b944a1 Ireland Region Ireland
Now we add some users to the new AU. The object identifier stored in the $AU variable is returned by the call to the New-AzureADMSAdministrativeUnit cmdlet. The reference object passed is the object identifiers for the Azure AD user account we want to add to the AU. You can find the object identifier for an account using the Get-AzureADUser cmdlet.
$AU = "0ee53a45-bbee-4571-a407-56acc0b944a1" Add-AzureADMSAdministrativeUnitMember -Id $AU -RefObjectId (Get-AzureADUser -ObjectId "[email protected]").ObjectId
AUs can store groups too, so we add a Microsoft 365 group to the mix:
$GroupId = (Get-AzureADGroup -SearchString "Group for Ireland").ObjectId Add-AzureADMSAdministrativeUnitMember -Id $AU -RefObjectId $GroupId
To check that the AU is populated correctly, we can fetch the set of object identifiers and use them to get the display names of the users and groups in the AU.
$UserIds = Get-AzureADMSAdministrativeUnitMember -Id $AU ForEach ($UserId in $UserIds) { Switch($UserId.OdataType) { "#microsoft.graph.user" { $DisplayName = (Get-AzureADUser -ObjectId $UserId.Id).DisplayName } "#microsoft.graph.group" { $DisplayName = (Get-AzureADGroup -ObjectId $UserId.Id).DisplayName } } #End Switch Write-Host $DisplayName }
To discover the administrative units a user account (identified by their object identifier stored in $UserObjectId) is in, run this code:
Get-AzureADMSAdministrativeUnit | Where { Get-AzureADMSAdministrativeUnitMember -Id $_.Id | Where {$_.Id -eq $UserObjectId }} | Format-table Description, DisplayName Description DisplayName ----------- ----------- U.S. Region United States Ireland Region Ireland
To assign delegated permission for the AU, run the Add-AzureADMSScopedRoleMembership cmdlet. The inputs are the object identifiers for
$DelegatedUser = Get-AzureADUser -ObjectId [email protected] | Select -ExpandProperty ObjectId $RoleObjectId = Get-AzureADDirectoryRole | Where {$_.DisplayName -eq "User Account Administrator"} | Select -ExpandProperty ObjectId $RoleMemberInfo = New-Object -TypeName Microsoft.Open.MSGraph.Model.MsRoleMemberInfo -Property @{ Id = $DelegatedUser } Add-AzureADMSScopedRoleMembership -Id $Au -RoleId $RoleObjectId -RoleMemberInfo $RoleMemberInfo
To check what delegated roles are assigned for an AU, we can examine each of the scoped roles and extract the role name and its holder.
$AUName = (Get-AzureADMSAdministrativeUnit -Id $AU).DisplayName ForEach ($ScopedRole in $DelegatedRoles) { $RoleName = (Get-AzureADDirectoryRole -ObjectId $ScopedRole.RoleId).DisplayName $RoleHolder = ($ScopedRole.RoleMemberInfo.DisplayName) Write-Host $RoleHolder "is assigned the" $RoleName "role for the" $AUName "Administrative unit" }
After setting up administrative units, populating them with accounts and groups, and delegating permissions, the users who will manage the AUs can sign into the Azure AD portal and go to the administrative units blade to see the AUs they can manage (Figure 1).
Opening an AU reveals the objects in the container divided into Users (Figure 2) and Groups.
The process for delegated administrators to manage objects in an administrative unit is limited only by the roles they are assigned. For instance, the Remove member option is unavailable to a delegated administrator because this action isn’t included in the User management role. However, a delegated administrator can update user account properties, change passwords, and assign licenses. Some training is probably necessary to make sure that delegated administrators understand what they can and cannot do.
One small but important point is that delegated management of group membership didn’t initially work in my tenant because the UsersPermissionToReadOtherUsersEnabled setting for Azure AD was set to False. I have no idea why this was the case, but it needed to be set to True to allow delegated management of group membership to work properly.
Set-MsOlCompanySettings – UsersPermissionToReadOtherUsersEnabled $True
Microsoft has acknowledged this as a bug and should fix it soon.
You might not want delegated administrators to go near the Azure AD portal. If the use case is password management (aka resets for users who forget their passwords), Microsoft’s My Staff feature (in preview – Figure 3) allows delegated administrators to perform a limited set of account maintenance actions, including password reset.
Administrators delegated the Authentication administrator role can go to the My Staff page to manage phone numbers used for MFA phone-based authentication requests. This is different to the phone number that most will think about, which is the number shown in the directory to contact people through.
Microsoft could upgrade My Staff to allow greater access to account properties and make it a more useful portal for delegated account maintenance. It will be interesting to see how this story develops
Support for Privileged Identity Management (PIM) is a recent addition to scoped management. PIM allows privileged access to be granted to accounts for a set period rather than perpetually, so if you want, you can limit the scoped assignments made for administrative units.
For more information about PIM in action, see this article.
You don’t need to use administrative units to manage Azure AD and for some tenants, AUs will be overkill. But for the largest and most complicated tenants, or those who divide operational responsibilities across different divisions, AUs can help them move away from the need to have many administrators with total power over Azure AD to a smaller set of global administrators backed up by delegates who manage parts of the directory.