Create and Manage Azure Active Directory Administrative Units

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.

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.

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:

PowerShell

1

Get-MsolAdministrativeUnit

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:

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:

PowerShell

1

Get-MsolRole

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)

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.

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:

MEMBER LOGIN:

BECOME A PETRI MEMBER:

About the Contributor

Russell Smith specializes in the management and security of Microsoft-based IT systems. In addition to blogging about Windows and Active Directory for the Petri IT Knowledgebase, Russell is a Contributing Editor at CDW’s Biztech Magazine. Russell has more than 15 years of experience in IT, has written a book on Windows security, co-authored one for Microsoft’s Official Academic Course (MOAC) series and has delivered several courses for Pluralsight.