This is especially true for large organizations or universities with multiple brands or decentralized administration within a single Office 365 tenant, the default admin roles can cause headaches. While the delegation of permissions in Exchange Online works very well with Role Based Access Control (RBAC), other applications and services are hard to manage at a granular level. For example, license management or helpdesk for different countries, brands, and organizations. In these organizations, only a subset of administrative users are allowed to edit properties based on their region or brand.
Azure Active Directory administrative units are a container of resources that can be used for delegating administrative permissions and applying policies to a subset of users. They enable central administrators to delegate permissions based on region, brand or to set a policy at a granular level. It simply groups your users into logical units. An admin will be able to perform various tasks against all users within the scope of an administrative unit.
At the time of writing, administrative units are still in public preview and the global admin needs to have an Azure Active Directory Premium licensed assigned while users within the administrative units needs Azure Active Directory Basic licenses. In this preview, only users can be assigned to resources. Once created and populated, the administrative unit can be used as a scope to restrict the granted permission only over resources contained in the administrative unit. Also, there are only two roles available: User Account Administrator and Helpdesk Administrator.
Before we can start, the Azure Active Directory Module public preview release needs to be installed:
Connect to Azure Active Directory with the Office 365 global admin:
This blog post covers three examples of delegated administration for the role “User Account Administrator” for a specific region, “Helpdesk Administrator” for users within a specific department, and we will scope an Exchange administrator to a specific administrative unit.
The following admin user accounts are available:
ObjectId DisplayName UserPrincipalName UserType
——– ———– —————– ——–
f1851b74-617d-40c9-8943-30ac58e84f48 Dominik Hoefling (atwork) [email protected] Member
6d381b8c-7e16-4601-81ab-79333efb61c6 Dominik Hoefling (Exchange Lab) [email protected] Member
“Dominik Hoefling (Exchange Lab)” is the user account administrator for US, Dominik Hoefling (atwork)” is the helpdesk administrator for Germany, and as well the Exchange administrator for a certain administrative unit.
Note: There are currently no parameters like -Department, -Office, or -Country. And there is no dynamic membership, you must manually add the users to the administrative unit, which also means you must keep it up to date. The -Country attribute in this blog is only used to easily add members to different administrative units.
The requirement is to have multiple user account administrators only for a subset of users within a specific region. This example allows the privileged user “Dominik Hoefling (atwork)” to administrate users based in US and deny administration for users located in Germany.
Run steps 1 – 5 with a global admin account:
- Enable the User Account Administration Role:
$UserServiceAdmin = Get-AzureADDirectoryRoleTemplate | Where-Object $_.DisplayName -eq “User Account Administrator”
Enable-AzureADDirectoryRole -RoleTemplateId $UserServiceAdmin.ObjectId
To get a list of all available role templates, run the Get-AzureADDirectoryRoleTemplate cmdlet.
- Create and populate the administrative unit:
New-AzureADAdministrativeUnit -Description “US region” -Displayname “US”
- Add user “Andreas Bode (Exchange Lab)” – or all your users based in the US – to the administrative unit:
$USAU = Get-AzureADAdministrativeUnit -Filter “displayname eq ‘US’”
$USUsers = Get-AzureADUser -Filter “UserPrincipalName eq ‘[email protected]'”
Add-AzureADAdministrativeUnitMember -ObjectId $USAU.ObjectId -RefObjectId $USUsers.ObjectId
- Add US-scoped admin user account “Dominik Hoefling (Exchange Lab)” role member:
$USUserAdmin = Get-AzureADUser -Filter “UserPrincipalName eq ‘[email protected]'”
$USUserAdminRoleMemberInfo = New-Object -TypeName Microsoft.Open.AzureAD.Model.RoleMemberInfo -Property @ ObjectId = $USUserAdmin.ObjectId
$UAUserAdmin = Get-AzureADDirectoryRole | Where-Object $_.DisplayName -eq “User Account Administrator”
Add-AzureADScopedRoleMembership -RoleObjectId $UAUserAdmin.ObjectId -ObjectId $USAU.ObjectId -RoleMemberInfo $USUserAdminRoleMemberInfo
- Get a list of US scoped administrative units admins:
Get-AzureADScopedRoleMembership -ObjectId $USAU.ObjectId | fl
AdministrativeUnitObjectId : 1141b4e9-a721-4331-afed-c669c7dc53d7
Id : cB-Eb4FD30G02cIJxg1lyum0QREhpzFDr-3GacfcU9eMGzhtFn4BRoGreTM–2HGU
RoleObjectId : 6f841f70-4381-41df-b4d9-c209c60d65ca
RoleMemberInfo : class RoleMemberInfo
DisplayName: Dominik Hoefling (Exchange Lab)
UserPrincipalName: [email protected]
- After this has been checked, log in to the Office 365 admin portal with the “Dominik Hoefling (Exchange Lab)” account and see what users and accounts can be managed
Only members in the administrative unit (step 3) can be viewed and edited with the “User Account Administrator” privileges.
The same behavior applies to Windows PowerShell:
Set-AzureADUserPassword -ObjectId “f1851b74-617d-40c9-8943-30ac58e84f48” -Password $password
Set-AzureADUserPassword : Error occurred while executing SetUser
Message: Insufficient privileges to complete the operation.
At line:1 char:1
+ Set-AzureADUserPassword -ObjectId “f1851b74-617d-40c9-8943-30ac58e84f …
+ CategoryInfo : NotSpecified: (:) [Set-AzureADUserPassword], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.Graph.PowerShell.Custom.C
The requirement is to have multiple helpdesk administrators for only a subset of users within a specific region. You can go through the same steps to configure the “User Account Administrator” administrative unit. If required, change the variables or the user filter on a different region, country or any other attribute. You only have to take care of the correct ObjectId’s of the administrative unit, admin role and your users.
Exchange Online Delegation
To begin with, it is not possible to create other administrative unit admin roles at the time of writing. For example, if you want to add the scoped role membership to the “Exchange Service Administrator”, you will receive the following error message:
Hopefully Microsoft will add more granular privileged admin roles in the future.
However, you can scope Exchange Online Role Based Access Control (RBAC) management roles to an administrative unit. In this example, we are using the built-in “Mail Recipients” role and delegating the admin role to the “Dominik Hoefling (Exchange Lab)” admin who can administrate only US-users within the formerly created administrative unit.
- change Online Remote PowerShell
- Assign the “Mail Recipients” role to the administrative unit:
New-ManagementRoleAssignment -Role “Mail Recipients” -RecipientAdministrativeUnitScope $USAU.ObjectId -User [email protected]
- The admin from Exchange Lab can only manage mailboxes within the Azure Active Directory administrative unit:
Left picture: at work (Germany) – no properties can be edited
Right picture: Exchange Lab (US) – properties based on the Mail Recipients role can be edited
Note: The documentation from 07/10/2017 is not correct because the parameter -DirectoryRole isn’t working, also for the latest AzureAD PowerShell module. Thus, I grabbed the ObjectId of the DirectoryRoleTemplate and pass it in as a string.
Azure Active Directory administrative units are a good step forward, but they definitely need some more granular privileged admin roles that can be used with other Office 365 applications and workloads (i.e. license management based on different companies and/or countries. As for now, you can scope the built-in roles “User Account Administration” and “Helpdesk Administrator”). For Exchange Online, you can scope RBAC to administrative units as well, which means you can cover mostly every requirement and workload at least for Exchange.