Azure AD Administrative units support expanded to some Purview Compliance solutions

As the Azure AD team continues to ramp up new features and functionalities for Administrative units, other teams within Microsoft are slowly adding (or expanding) support for AUs within their respective admin tools and interfaces. One such example comes from the Purview Compliance team, which recently announced a public preview of Administrative units support in Microsoft Purview. Let’s see how it works.

What are scoping controls

Even to this day, the RBAC model used by the Purview compliance center closely resembles the model used by Exchange Online, albeit with some restrictions. We’ve covered some of the peculiarities back in the days when it was called the Protection center, and later the Security and Compliance Center. The same building blocks determine which specific operations a given user can perform (the “what” part), via the set of Roles and Role Groups assigned to the user (the “who” part). Unlike Exchange Online RBAC however, the “where” part of the model never got ported to the Compliance controls. That is, management scopes are not available and any role assignments are made with the global scope.

Until now that is. Soon after Exchange Online added support for management scopes based on Administrative units, the functionality was also ported to the Purview compliance center, and we can now scope Role Group assignments. Not every feature within the Compliance center is currently supported however – according to the official documentation only the DLP and Sensitivity labels solutions can use such scoped assignments. Some additional features, such as DLP Alerts and Activity explorer seem to also support this functionality in the preview phase.

While the documentation also claims that every custom Role group can be scoped via Administrative units, it looks like not every built-in Role group is currently supported. The following list includes all the supported Role groups:

• Compliance Administrator
• Compliance Data Administrators
• Global Reader
• Information Protection
• Information Protection Admins
• Information Protection Analyst
• Information Protection Investigators
• Information Protection Readers
• Organization Management
• Security Administrator
• Security Operator
• Security Reader

And while we are on the subject of restrictions, you will also need to have appropriate licenses in order to use this functionality. Apart from the Azure AD Premium plan needed for Administrative units, the documentation lists only the following plans as supported: Microsoft 365 E5, Microsoft 365 E5 Compliance and Microsoft 365 E5 Information Protection & Governance. Those are some unfortunate restrictions, but they reflect the overall trend of “every feature now needs M365 E5 license” we’ve seen in the compliance space. Evergreen service, for sure.

Creating an AU-scoped role group assignment

Now that we have an idea what the feature is, let’s see how we can put it to use. The easiest way would be to open the Roles & Scopes > Permissions page within the Purview Compliance center, then hit the Roles link under Microsoft Purview solutions. This will take you to the Role groups management interface, where you can select one of the built-in Role groups, such as Compliance administrator, then press the Edit button. In turn, this takes you to the Edit members page of the Edit Role group wizard, where you can add or remove users (or groups) as needed.

On this page, you will also find the scoping controls, in the form of the Assign admin units button. The process here is a bit counter-intuitive, as the Assign admin units button is grayed out by default. To create a scoped assignment, you first need to add the user, then select him in the list of assigned users and only then manage the scope. In other words, by default assignments are created with the global (organization-wide) scope. In contrast, assigning scoped roles within the Azure AD UI first requires you to select the scope, whereas the Microsoft 365 admin center UI only allows AU-scoped assignments by first selecting the AU, then the Role and finally the user. Overall, each admin endpoint uses its own flow, which is hardly surprising, considering how little the various teams within Microsoft interact with each other…

Anyway, to create an AU-scoped assignment, proceed to select the user you want, then hit the Assign admin units button. And yes, the name of the button doesn’t even spell administrative units, aesthetics win over terminology. Once you hit the Assign admin units button, you will be presented with a new pane, featuring a list of all administrative units within the organization. You can select one or more AUs at this point (another difference with the flow in other admin UIs), then press the Select button to confirm the changes. At this point, the assignment will be changed to AU scoped:

Proceed with clicking the Next button to confirm the changes to the Role group membership. On the Review and finish page, you will be presented with a summary of the changes made, and clicking the Save button will confirm them. Job done.

Purview UI experience when using an AU-scoped assignment

Let’s now see how the newly assigned scoped permissions behave. As usual with any role assignments, it’s advisable to wait a few mins before testing, and logout of any active sessions to force the issuance of a fresh access token. Using a private browser session is usually an acceptable workaround. As a first test, I was interested to check the experience with any of the functionalities/solutions not listed as currently supported (as mentioned above, only DLP and Sensitivity labels are currently supported). Logging in with a user with a scoped assignment to the Compliance administrator role does expose most (all?) UI elements within the Purview Compliance portal, however this doesn’t necessarily mean the user can access them.

For example, our scoped admin can access the Content search page and will in fact obtain a list of all searches within the organization. Moreover, he can select any existing search and rerun it. And he can even create new content searches! When it comes to previewing or exporting the results however, the operation will be restricted. So, we have some mixed results, but overall we should not expect any of the unsupported functionalities to work. In contrast, a user with the same Role group assigned, but not scoped to an Administrative unit, can use the full Content search functionality, including the preview and export features (subject to any Compliance security filters of course).

Next, let’s focus on what’s actually supported and supposed to work. As mentioned above, currently the DLP and Sensitivity labels solutions are supported. Do note however that not all functionalities within said solutions are actually covered. In fact, it’s only the Policies aspect of both that does support Administrative units currently. When accessing any page within said solutions, an info tip on top will inform you about possible restrictions. It reads something like this:

If your role group permissions are restricted to a specific set of users or groups, you’ll only be able to manage policies for those users or groups.

As with the case of Content search, having an AU-scoped assignment does not actually prevent the user from listing all Sensitivity labels within the organization, for example. In fact, such users can even make changes to labels, so be warned! The restrictions come into play only when accessing the Policies page, where a user with AU-scoped role will only be able to see and work with policies assigned to said Administrative unit, and not with any of the “global” ones. Which begs the question, how does one assign an AU to a DLP or Sensitivity label policy?

Creating an AU-scoped DLP policy

The answer is again not as straightforward as it should be. One would expect that any admin with sufficient permissions would be able to configure such a policy, and you get the same impression when you use the Create/edit policy wizard and arrive at the Admin units (preview) tab, where you’ll be greeted by the following text:

When it comes to DLP policies, pressing the Add or remove admin units button is useless, unless the current user has been assigned to an AU-scoped Role group. In other words, if you hit the button with a Global admin or (unscoped) Compliance admin user, the list of Administrative units to select from will be empty, and in effect, you can only configure the policy as unscoped. For Sensitivity label policies, the functionality seems to work as expected, and an unscoped admin can create either a global or AU-scoped policy

For DLP policies, in order to create a scoped policy, you need to login with an admin user that has at least one AU-scoped assignment. In which case, the list of AUs to select from will be populated, and the text is changed to inform you that you must select an AU, before pressing the Next button.

Yet another interesting observation is that the UI will actually enforce the Microsoft 365 E5 licensing requirement at this point of the process. While I can understand the desire to drive consumption of the higher SKUs, both DLP and Azure AD Administrative units are functionalities included in existing “lower tier” licenses, and this is certainly not functionality that justifies the need for E5 license, and Microsoft 365 E5 one at that.

Moving on. After selecting the AU(s), the next set of challenges will be presented on the Locations tab. Herein, the SharePoint sites, On-premises repositories and Power BI locations (for DLP policies) will be grayed out. This makes sense, considering such objects cannot be members of an Administrative unit. For the rest of the location types, you can choose to cover All entries, or limit the scope, like you would with a “regular” DLP policy. However, when selecting a user or group to include, you are now limited to just the set of objects that are members of the Administrative unit(s) you selected in the previous step.

This again makes some sense, but it also limits the usability of the feature in certain scenarios. For example, in the case of the Exchange location, the UI by default only allows you to select a Distribution list instead of individual users, which in turn further limits your options. Other issues seem to be encountered with AUs with dynamic membership. Whereas an unscoped admin was able to see all current members of the AU, a user with a scoped assignment only got 2 results. The issue seems to stem from the underlying execution of the Get-ScopeEntities cmdlet, but that’s a story for another time I guess.

Anyway, this step is of course optional, and can be skipped. Continue with configuring the rules as needed and finish up building the policy. Once created, the new policy should be visible to anyone with an admin role scoped to the corresponding AUs, and all the admins with global scope. The latter will still have issues editing the policy, for example the blank selection in the AU picker pane shown below:

How things look like via PowerShell?

In case you were wondering, here’s how the properties of an AU-scoped DLP policy look like via PowerShell. The PolicyRBACScopes property contains the only important bit, namely the GUID of the Administrative unit assigned to our policy. All of the *Location and *LocationException properties remain blank or list “All” as the entry, thus you need to always check the presence of the PolicyRBACScopes GUID to properly cover the set of objects under the policy’s scope.

Another interesting property is the UserAdministrativeUnitMembershipMap one, however it seems to not be populated in my case.

Unfortunately, there doesn’t seem to be a way to list AU-scoped assignments via PowerShell currently, as the corresponding Get-ManagementRoleAssignment cmdlet is not available within the Security and Compliance Center PowerShell module. We can however obtain some details from the Unified Audit log. The Operation/activity type is GrantPermissionsAsync, which is another indication that the assignment is done outside of the regular PowerShell module. Here’s an example event:

$res = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Operations GrantPermissionsAsync

$res[2].AuditData | ConvertFrom-Json

$message = ($res[2].AuditData | ConvertFrom-Json).PostExecutionMessage
$message.Replace("result=","") | ConvertFrom-Json

RoleIdentifier : @{RoleType=RBACRoleGroup; Name=InformationProtectionAdmins; RoleId=5a544c88-e0d6-9027-a7c9-95f7a3a9a7aa}
GrantType : Grant
CredIdentifier : @{AudienceType=TenantUser; Name=GradyA@M365x60680951.OnMicrosoft.com; AudienceId=0ad6602d-afe0-4316-bf05-9610005c597e; DisplayName=Grady Archie}
ScopeId : 147cebb2-9e0a-42f9-958a-fd43d5b818b5
ScopeFeature : All
ScopePathByName : /ResourceType:Geo/name:Sales team
ScopePathById : /ResourceType:Geo/id:147cebb2-9e0a-42f9-958a-fd43d5b818b5
ScopeResourceType : Geo
RestrictionIdentifier :
AADRoleMappedRoleIdentifiers :
ValidTillDatetime :
ExtraInfo :
RoleSet : UCC
RoleAudience : Tenant
AuxUniqueKey : 5a544c88-e0d6-9027-a7c9-95f7a3a9a7aaGrant0ad6602d-afe0-4316-bf05-9610005c597e147cebb2-9e0a-42f9-958a-fd43d5b818b5
AuxUniqueKeyById :
MarkDeleted : False
TenantId : 8c67d2aa-8392-4bf2-91a0-82c0b00bc132
id : permission7db2f843-c0d9-4758-9b3b-594eec3aab4f
CreationDateTime : 2023-04-10T10:32:59.2959486Z
LastModifiedDateTime : 2023-04-10T10:32:59.2959486Z
_rid : iyM6AM9MjyTxzYAAAAAABA==
_self : dbs/iyM6AA==/colls/iyM6AM9MjyQ=/docs/iyM6AM9MjyTxzYAAAAAABA==/
_ts : 1681122779
_etag : "fc002e45-0000-0700-0000-6433e5db0000"

And here’s the corresponding audit trail for a DLP policy creation operation:

$res2 = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Operations New-DlpCompliancePolicy
$res2.AuditData | ConvertFrom-Json

CreationTime : 2023-04-10T12:53:19
Id : 1fcfd96d-87d1-4b15-a667-6a5fb9b013b6
Operation : New-DlpCompliancePolicy
OrganizationId : 8c67d2aa-8392-4bf2-91a0-82c0b00bc132
RecordType : 18
ResultStatus : Success
UserKey : GradyA@M365x60680951.OnMicrosoft.com
UserType : 2
Version : 1
Workload : SecurityComplianceCenter
ObjectId : a18ed94d-857a-4b48-96f8-4d7bed36ee05
UserId : GradyA@M365x60680951.OnMicrosoft.com
SecurityComplianceCenterEventType : 0
ClientApplication : EMC
CmdletVersion : ...
EffectiveOrganization : M365x60680951.onmicrosoft.com
NonPIIParameters : -Name "<SNIP-PII>" -Comment "<SNIP-PII>" -Mode "<SNIP-PII>" -ExchangeLocation ("<SNIP-PII>") -OneDriveLocation ("<SNIP-PII>") -TeamsLocation ("<SNIP-PII>")
-EndpointDlpLocation ("<SNIP-PII>") -PolicyRBACScopes ("<SNIP-PII>")
Parameters : -Name "Custom policy" -Comment "Create a custom policy from scratch. You will choose the type of content to protect and how you want to protect it." -Mode
"Disable" -ExchangeLocation ("All") -OneDriveLocation ("All") -TeamsLocation ("All") -EndpointDlpLocation ("All") -PolicyRBACScopes
("147cebb2-9e0a-42f9-958a-fd43d5b818b5")
StartTime : 2023-04-10T12:53:19

The highlighted part indicates the important bit – the use of the –PolicyRBACScopes parameter to restrict the scope of the policy!

Summary

In summary, Microsoft is rolling out the first bits to support Administrative units within the Purview compliance portal. The preview is limited to DLP and Sensitivity label policies only, and certainly has some rough edges. While I’m sure Microsoft will sort most of these out, the requirement for Microsoft 365 E5 license is something that will impact the use of these new controls, and frankly, it’s just another expression of corporate greed. The RBAC model itself and the flows used within it might benefit from some adjustments to bring them closer to the behavior we’ve observed in other parts of the service for years now. Then again, various teams within Microsoft seem to have their own opinions on how certain functionalities should work, even when the fundamentals are involved, so I wouldn’t hold my breath for a uniform experience.