A while back, we covered the introduction of support for scoping (some) Purview Compliance Center role groups based on membership of administrative units. At that time, only the DLP and Sensitivity labels “solutions” supported this functionality. Now, Microsoft has added support for scoping Audit permissions too, as noted in Roadmap item 163961. In turn, this allows organizations to grant scoped access to the events held within the Microsoft 365 Audit log. Let’s take a look!
First, let’s head over to the Permissions tab and create a new role assignment, scoped to an administrative unit. To do this, navigate to the Purview compliance center > Permissions and click Roles under the Microsoft Purview solutions group. Once the set of Role groups loads, we can either select one of the built-in roles that grant access to the Audit functionality, such as the Audit Reader and Audit Manager, or create a new custom Role group. For the sake of simplicity, let’s stick with the former, and select the Audit Reader group, then hit the Edit button to make the changes.
Once the wizard dialog pops up, you will be taken to the Edit members of the role group screen (shown below). Herein, you can designate one or more users as members of the selected Role group, or add them based on a group membership, by selecting the Choose users or Choose groups buttons, respectively. Again, let’s keep things simple and select a single user, say Gosho. At this point, if we confirm the changes we will create an unscoped, org-wide assignment for the user, as indicated by the Organization label under the Admin units column. To make this a scoped assignment instead, select the user entry and hit the Assign admin units button. Therein, select one or more of the administrative units configured within your organization, then confirm the changes. Voila!
We have now effectively granted the user (Gosho) permissions to perform any of the operations allowed by the Audit reader role, but only against the set of users who are members of the Shared mailboxes only Administrative unit. The expected behavior would be that any Audit log searches said users performs will be restricted to just audit events corresponding to members of said administrative unit. Let’s head over to the Audit page and verify this (don’t forget to confirm the changes to the role group above).
As with most permissions-related changes, it’s best to open a new private session (or relog) in order to refresh the set of roles/permissions assigned to the user. Then, head over to the Audit page, and make sure to select the New Search experience (the classic one does not seem to be updated to reflect this functionality). Herein, you will be greeted with a banner on top, informing you that the permissions on the user are restricted, as shown on the screenshot below. In addition, the newly introduced Admin units control will only list the AUs we scoped the Role assignment to, in our case Shared mailboxes only.
Of course seeing a banner or having the AU hide some choices doesn’t necessarily translate into limited search capabilities, so let’s see what happens when we query the Audit log. Let’s do a blanket search that includes any and all activities from the past day, then compare the results with the same search run by a user with unscoped assignment to the Audit search functionality. The results are shown on the screenshot below:
Whereas the unscoped search returned an estimate of 879 items, the search we run with the user with the AU-scoped assignment returned an estimate of 158. We did cheat a bit here though, as the original scope assignment (to the Shared mailboxes only AU) returned zero results, due to the limited number of audit entries generated for members of said AU, so the role assignment was updated to include another AU in its scope.
Now, you might ask why we decided to run a search for the default timeframe, instead of something broader, which will of course return more results. Well, in typical Microsoft fashion, the newly added functionality is not without its issues, and the UI currently bugs out whenever you try to change the date/time selection. Every single time you get an “Start/end date should be in valid format and the start date is earlier than end date.” error and are prevented from starting the search. This is specific to the user with AU-scoped role assignment, whereas a “regular” user with unscoped assignments can change the time range just fine.
The disappointment doesn’t end here sadly, as Microsoft has neglected to “port” this functionality to the good old Search-UnifiedAuditLog cmdlet. Specifically, the scoped role assignment we created for the user Gosho does not grant him sufficient permissions to run the Search-UnifiedAuditLog cmdlet. We can of course remedy that, by creating an AU-scoped role assignment on Exchange side of things (check out this article in case you missed the news about this functionality):
New-ManagementRoleAssignment -Role "Audit logs" -RecipientAdministrativeUnitScope b42de8c9-7062-4cc0-8c85-f6ae79bdb839 -User gosho@michev.info
With the newly created AU-scoped role assignment, Gosho can now login via Exchange Online PowerShell and run the Search-UnifiedAuditLog cmdlet, to the same effect as the UI-based approach. Well, objectively better, considering we can use custom date ranges herein. As before, the set of results will be scoped to just members of the selected AU(s), as illustrated below:
Note not just the difference in the number of results returned, but also the set of UserIds – both indicate that the search performed by the user with the scoped role assignment has been trimmed to just members of the AUs in question.
And with that, we can close our article on the recently introduced support for administrative units within the Purview Audit “solution”. While there are some rough edges for Microsoft to sharpen, the feature overall works as expected and will finally be able to address the requirements of customers that wanted scoped access to the Unified audit log data mart. With a simple to configure AU-based assignment, you can scope the set of results returned from Unified audit log queries to just users from specific departments, countries or business groups. Do note that not every workload supported by the Unified audit log offers support for administrative units though, so the resulting set of audit log entries the user will have access to might be smaller than expected, and will lack any “system” events, as well as events from unsupported workloads.