Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET Coming Soon: GET:IT Endpoint Management 1-Day Conference on September 28th at 9:30 AM ET
Azure Active Directory|Office|Office 365

Working with Azure AD Administrative Units

Logical Division of Azure Active Directory Management

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.

Sponsored Content

Say Goodbye to Traditional PC Lifecycle Management

Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.

Management Options

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.

PowerShell and Administrative Units

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 }
     "" {
        $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

  • The user account receiving delegated permission. This is passed in a RoleMemberInfo object.
  • The delegated role.
  • The administrative unit.

$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" }

The View from the Azure AD Portal

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).

Image 1 Expand
Figure 1: Administrative units available to a delegated administrator (image credit: Tony Redmond)

Opening an AU reveals the objects in the container divided into Users (Figure 2) and Groups.

Image 2 Expand
Figure 2: Users in an administrative unit (image credit: Tony Redmond)

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.

My Staff

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.

Image 3 Expand
Figure 3: User accounts from an administrative unit listed in the My Staff page (image credit: Tony Redmond)

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

Privileged Identity Management

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.

Administrative Units Useful for Some, Not All

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.


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (4)

4 responses to “Working with Azure AD Administrative Units”

  1. <p>Hi Tony, you can also manage AUs via the new MSGraph PowerShell modules:</p><p><br></p><p><span style="color: rgb(47, 47, 47);">Install-Module Microsoft.Graph</span></p><p>Get-Command -Module Microsoft.Graph.Identity.DirectoryManagement</p><p><br></p><p>See here for other info:</p><p>This would be the supported way going forward: as AAD Graph is being deprecated:</p><p></p><p>also PowerShell module based on AAD Graph will be deprecated (no dates are announced yet).</p>

    • <blockquote><a href="#16933"><em>In reply to licantrop0:</em></a><em> I think it will take a while for the Graph PS modules to take the place of what we have today. Although Microsoft has indicated an intention to deprecate in 2022, there's a ton of time between now and then. Most if not all people use the Azure AD module, so that's what I used for this article – and I spent a lot of time corresponding with the dev group because of some errors that I encountered.</em></blockquote><p><br></p>

  2. <p>We have a government customer with 70,000 users in a tenant. Each agency is a unique scope. They seem to be successful in partioning administration.</p><p><br></p><p>How specifically would AU's compliment or replace a scope ?</p>

    • <blockquote><a href="#16936"><em>In reply to vern:</em></a><em> I couldn't possibly comment because I don't have enough information to say anything intelligent.</em></blockquote><p><br></p>

Leave a Reply

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He covers Office 365 and associated technologies for and is also the lead author for the Office 365 for IT Pros eBook, updated monthly to keep pace with change in the cloud.