Administrative Units (AUs) are logical entities that allow Azure Active Directory (AAD) tenant administrators to limit the scope of AAD administrative roles, such as User Account Administrator. Still in public preview at the time of this writing and only available as part of an AAD Premium subscription, the ability to limit the scope of administrative roles gives tenant administrators greater flexibility when assigning permissions.
In this article, I’ll walk you through upgrading to an Azure AD Premium trial and show you how to create and manage Administrative Units with PowerShell so that you can limit the scope of administrative roles to specific AUs.
Upgrading to AAD Premium
You’ll need to upgrade to AAD Premium before it’s possible to use Administrative Units. If you don’t already have a premium subscription, you can upgrade to a trial by following the instructions below. Open the Azure management portal and sign in:
In the blue panel on the left, scroll down and click ACTIVE DIRECTORY.
On the right of the portal, click the AD that you want to upgrade. In the GET STARTED section, click Try it now under Get Azure AD Premium.
You’ll be redirected to the Licenses tab. Click TRY AZURE ACTIVE DIRECTORY PREMIUM NOW.
In the Activate Azure AD Premium trial dialog, click OK to confirm that you want to enable the 90-day trial.
You might need to wait a few minutes while the trial is set up.
Upgrading to Azure Active Directory Premium. (Image Credit: Russell Smith)
If you already have the AAD module for Windows PowerShell installed, you can check the version number by running the cmdlet below in a PowerShell prompt. If it’s lower than 1.0.8070.2, then you’ll need to update the module.
Before installing the new AAD module, remove Windows Azure Active Directory Module for Windows PowerShell, or Microsoft Online Services Module for Windows PowerShell if already installed on your PC.
Connecting to Azure Active Directory
To make a connection to your Azure Active Directory subscription, run the following PowerShell cmdlet and enter the account information for a Global Administrator:
Creating an Administrative Unit
Once you've got your management PC set up and made a connection to your AAD subscription using PowerShell, you can create an Administrative Unit using the New-MsolAdministrativeUnit cmdlet:
Creating a new Administrative Unit with PowerShell. (Image Credit: Russell Smith)
To confirm that the AU was successfully created and to see any other AUs that might already exist in AAD, run the command below and you should see the new Administrative Unit listed in the output:
Adding a User to an Administrative Unit
Before we can add users to the AU, we need to get both the user's and AU's object IDs. In this example, I'm going to add a user account (user1) to the London AU, and another user (useradmin) to the User Account Administrator role, scoped by the London AU, meaning that useradmin will only be able to modify account parameters for user accounts associated with the London AU. It should also be noted that users can be associated with more than one AU.
If you want to add a new user to AAD for the purposes of this exercise, run the New-MsolUser cmdlet as shown, replacing mydomain.onmicrosoft.com with your domain name as appropriate:
Now we'll create two variables to hold the relevant objects for user1 and the London AU, respectively:
While it's not necessary, if you want to see the actual object IDs in the console, run the following two Write-Host cmdlets:
Finally, we'll use the Add-MsolAdministrativeUnitMember cmdlet to add user1 to the AU:
To confirm that user1 is now associated with the London AU, run the command below and you'll see a list of the AUs that user1 belongs to:
Adding a user to an Administrative Unit. (Image Credit: Russell Smith)
Alternatively, you can list all the users associated with a given AU using the Get-MsolAdministrativeUnitMember cmdlet:
Scoping Administrative Roles
Now we have an AU with at least one associated user, we need to add useradmin to the User Account Administrator role, but scoped by the London Administrative Unit. Remember that this means useradmin will only be allowed to perform actions permitted by the User Account Administrator role on users associated with the London AU, not on all AAD users.
Let's start by listing all the defined roles in AAD:
I'll reuse the $au variable defined in the last step and add the $role variable to hold information about the User Account Administrator role. I'll also redefine the $user variable to get the object ID for the useradmin account, which I've already created in AAD.
The Add-MsolScopedRoleMember cmdlet adds useradmin to the User Account Administrator role, but limits the user's scope as defined by the specified Administrative Unit:
Adding a user to a role scoped by Administrative Unit. (Image Credit: Russell Smith)
To check that the user was added to the role and scoped by AU, run the command below. All users that are a member of the given role and scoped by the specified AU will be listed in the output:
Testing the Results
As my directory currently stands, useradmin should be able to perform any User Account Administrator operations on user1, but not on any other users because they are not associated with the London AU.
So I'll log in with the useradmin account and try to set the UsageLocation parameter for user1, which needs to be a two letter country code. To log in with a different user account, I need to run Connect-MsolService again.
Setting properties on an Azure Active Directory User. (Image Credit: Russell Smith)
If the command runs successfully, there will be no output in the PowerShell prompt. But if you try to run the command again against a user that's not associated with the London AU, PowerShell will return an error: Set-MsolUser : Access Denied. You do not have permissions to call this cmdlet. We get this error because I'm trying to set the UsageLocation parameter on a user that isn't associated with any AU.
Removing Users from Scoped Roles and AUs
Let's reverse all the configuration we performed above. We'll start by removing useradmin from the scoped administrative role. In the Remove-MsolScopedRoleMember cmdlet below, I'm continuing to use the variables defined in the previous steps. Don't forget, you will need to use Connect-MsolService again to sign in with a user that has been assigned the Global Administrator role to run the cmdlets below:
To check that useradmin has been removed from the scoped role:
Removing a user from a role scoped by Administrative Unit. (Image Credit: Russell Smith)
Now let's remove user1 from the London AU:
And to check the current users associated with the London AU:
Removing an Administrative Unit
Finally, if you want to delete an Administrative Unit, use the Remove-MsolAdministrativeUnit cmdlet with the AU's object ID:
