Administrative units and Microsoft Purview

Reading time: 2 minutes

Introduction

Some of you might have noticed, either in Azure Active Directory or Microsoft Purview, the appearance of Administrative Units or Admin units (preview). As these are now available, I wanted to know more about these units and why they are included in Microsoft Purview. Time to take a closer look.

Directories

I have worked with Active Directory and Azure Active Directory (and other non-Microsoft directories) for many years. And although I’m by no means a directory expert, I do recognize the differences between the on-premises Active Directory and Azure Active Directory. And one of the most apparent differences is the use of Organizational Units (or OUs) in Active Directory or other types of X.500 directories (like IBM Domino).

An OU allows you to make the directory more manageable. Bringing together users, groups, and computer objects in manageable units. And also, being able to assign specific admin- and support roles to these units.

And although Azure Active Directory uses (static and dynamic) roles, it basically offers a very flat structure. It does not offer OUs, basically. And even though it offers many security-related features for the administrator roles (RBAC, Privileged Identity Management, Identity Governance), it is (or was?) not possible to scope admin roles. An administrator in the User Admin role was able to use this role to manage all users in the tenant.

Administrative units (AUs?)

The OUs within Azure Active Directory are the new Administrative units or AUs. Sorry – I had to do this 😉 Or, as I understand this. In this article, I won’t go into depth on this. But I do want to share some context.

AUs, now in preview, allow you to have more granular control over users and devices. It is not, however, an Azure AD security group. According to Microsoft:

It can be useful to restrict administrative scope by using administrative units in organizations that are made up of independent divisions of any kind. Consider the example of a large university that’s made up of many autonomous schools (School of Business, School of Engineering, and so on). Each school has a team of IT admins who control access, manage users, and set policies for their school.

https://learn.microsoft.com/en-us/azure/active-directory/roles/administrative-units

In Microsoft’s example, anyone in the Global Administrator or Privileged Role Administrator role can create an administrative unit for the School of Business, add users to this AU, create an administrative role scoped to this AU, and add administrators to this role.

And I guess that this makes sense and I can understand this. But why do these AUs appear in parts of Purview all of a sudden?

Microsoft Purview

Microsoft Purview (Compliance) has several platforms that use policies that are based on specific locations or users within the tenant. And for three of these platforms, the new AUs have been added:

• Microsoft Purview Information Protection
• Microsoft Purview Data Loss Prevention

This made me wonder; would this imply that by using these AUs, the policies could be applied even more stringently? Time to find out.

Test this out

In order to test this out, I’m using a specific user and Azure AD Microsoft 365 Group. The user is part of this group. I’ve created an Administrative Unit called the Demo admin unit. Yeah – very innovative, I know 🙂 The user was first added to this AU. After testing, the Microsoft 365 Group was also added.

When creating a policy for one of the Purview platforms named above, you can now select the required AU. And this affects the scope of the policy. This would allow you more granularity when creating such policies. So let’s take a look.

When you select the AU or AUs, the options for the location of the policy change.

You might notice already that these AUs only work for specific locations. Some locations do not support this at all:

So what does work? I’ve created a small table for this.

Data Loss Prevention

Scope AU	EXO	OneDrive	Teams	Devices
User	Nothing	User	User	User
User and M365 Group	M365 Group	User & M365 Group	User & M365 Group	User &M365 Group

For Information Protection the table is simple. An AU with only one user will target the sensitivity labels for that user. If a group is added, then the users in this group are also targeted.

So do note the Exchange Online location. You cannot use this location and an AU when this AU only contains users. Exchange Online is limited to distribution groups. Also note the locations which (at this moment) do not support AUs, including SharePoint Online.

To wrap up

AUs are still in preview, so we will need to look at how these will evolve. I do like the concept and that is applicable to certain Microsoft Purview platforms. Do remember that AUs are just this: administrative units that will not impact the working of the platforms. For example: in Information Protection I can use different policies to differentiate between groups of users. Now I can use AUs as well. But an Information Protection policy goes beyond targeting users. It also has specific settings that apply to these users. AUs will not offer this.

But AUs will allow you to better segmentize your user population. But for now, the most impact will be within Azure Active Directory. More information? Go to: https://learn.microsoft.com/en-us/azure/active-directory/roles/administrative-units