New Audit Events Capture User Access to Purview Solutions

Use Audit Events to Understand Who Accesses Purview Portal

I’m not quite sure who wrote the text for message center notification MC1473155 (last updated 13 October 2026, Microsoft 365 roadmap item 569363), but they certainly have a talent for obfuscation. The post is titled “permissions audit log improvements.” The text goes on to say that Microsoft is “enhancing audit logging for permission checks performed in the Microsoft Purview portal” by introducing new audit records.

Apparently, a lack of visibility exists into how users access the Microsoft Purview portal, so new audit records are captured for “role and scoped-role authorization decisions” with the intention that administrators can “investigate access issues and better understand how access evaluations are performed.”

This text comes from the update message center notification and is as clear as mud. Let’s parse what the update really means.

The Two New Audit Records

Users need authorization to access the Microsoft Purview portal. Access is granted on the basis of roles. Purview supports a mixture of Entra ID roles such as Global administrator which apply tenant-wide, and RBAC roles such as Audit manager. Purview RBAC roles can be scoped so that permissions apply only to a subset of resources.

An example of scoped-role authorization is where a user is assigned the eDiscovery manager role which is scoped so that they can only manage specific eDiscovery cases. Entra ID roles always take precedence over RBAC roles.

The change described in MC1473155 is that Purview generates audit records when it performs access checks to evaluate whether users can access solutions through the Purview portal. In line with the different ways Purview evaluates permissions, it generates either a CheckUsersInRoles audit record when checking role membership or a CheckUserInRolesWithScopes audit record when scope evaluation is also required.

The audit records are logged as events for the SecurityComplianceRBAC workload. As you’d expect, Purview generates the audit records only after the update is enabled within a tenant.

Example of Access Check Audit Record

Figure 1 shows an example of a CheckUserInRolesWithScopes audit record for a failed access. In this case, the user attempted to access the eDiscovery solution without one of the required Entra ID or RBAC roles needed to permit access. The PostExecution property shows that Purview blocked access for multiple roles required by eDiscovery.

An example of a successful access check logged in a PostExecutionMessage property in an audit record is:

Result: {"Allowed":2,"Blocked":0,"RoleAllowedWithScopeLogInfos":[{"IsScoped":false,"RoleName":"RoleManagement","AccessDecision":"Granted"},{"IsScoped":false,"RoleName":"ViewOnlyRoleManagement","AccessDecision":"Granted"}]}

Reporting the Audit Records

Scanning the audit log for individual records is interesting once in a blue moon. It’s more effective and efficient to extract the target audit records programmatically and analyze the results. Usually, I’d write a quick PowerShell script to use the Search-UnifiedAuditLog cmdlet to find the records, but in light of Microsoft’s decision to retire the cmdlet next year, here’s how to submit an audit query job to fetch the audit records for Purview access using the AuditLogQuery Graph API:

$AuditJobName = ("Purview Access audit job created at {0}" -f (Get-Date -format 'dd-MMM-yyyy HH:mm'))
$AuditQueryStart = ((Get-Date).AddDays(-7).toUniversalTime().toString('yyyy-MM-ddTHH:mm:ss'))
$AuditQueryEnd = ((Get-Date).AddHours(1).toUniversalTime().toString('yyyy-MM-ddTHH:mm:ss'))
[array]$AuditOperationFilters = "CheckUsersInRoles", "CheckUserInRolesWithScopes"

$AuditJob = New-MgSecurityAuditLogQuery -DisplayName $AuditJobName -OperationFilters $AuditOperationFilters -FilterStartDateTime $AuditQueryStart -FilterEndDateTime $AuditQueryEnd

After a while, the audit records should be ready for download. As explained in this article, interpreting audit log output differs when records are fetched by a Graph query. They also differ between running queries with Graph API requests and Microsoft Graph PowerShell SDK cmdlets. The code below uses the format generated by the Get-MgSecurityAuditLogQueryRecord cmdlet. Note that the audit record only includes the object identifier for the user account, so a separate call is needed to fetch the display name or user principal name. That’s annoying and wasteful.

In any case, this simple code tells us who’s been granted access to the Purview portal:

$Report = [System.Collections.Generic.List[Object]]::new()
# Get service principals to interpret app names
$SP = Get-MgServicePrincipal -All

ForEach ($Rec in $AuditRecords) {
  $AuditData = $Rec.AuditData.additionalProperties
  $Result = ($AuditData.PostExecutionMessage -replace '^Result:\s*') | ConvertFrom-Json
  $User = Get-MgUser -UserId $Rec.UserId
  $AppName = $SP | Where-Object {$_.AppId -eq $AppId} | Select-Object -ExpandProperty DisplayName
  If ($null -eq $AppName) { $AppName = "Unknown app" }
  [array]$RoleInfo = $null
    ForEach ($Role in $Result.RoleAllowedWithScopeLogInfos) {
      [string]$RoleOutput = ("{0} ({1})" -f $Role.RoleName, $Role.AccessDecision)
      $RoleInfo += $RoleOutput
    }
  $ReportLine = [PSCustomObject]@{
    TimeStamp = Get-Date $Rec.CreatedDateTime -format  'dd-MMM-yyyy HH:mm' 
    User      = $User.displayName
    Action    = $Rec.Operation
    Roles     = $RoleInfo -join ", "
    AppName   = $AppName
  }
  $Report.Add($ReportLine) 
}
$Report = $Report | Sort-Object {$_.TimeStamp -as [datetime]}

Figure 2 shows the kind of output you can expect. As you can see, no CheckUsersInRoles events occurred. So far, every access check I have captured has used CheckUserInRolesWithScopes. Perhaps standalone role checks (CheckUsersInRoles) will become more apparent over time. Worldwide deployment was scheduled to be complete by the end of October. The app name reported in the audit records always seems to be “Protection Center,” the old name for the Purview portal.

Audit Data is Always Useful

Having access to information that tells you how Microsoft 365 works is always beneficial. We’ve survived ten years since the introduction of the unified audit log without these events. Perhaps they should have come sooner, or maybe it’s just that people have realized that it’s good to log access to sensitive information, which Purview solutions undoubtedly process. Either way, the events are available for your auditing pleasure now.

---

Microsoft 365 for IT Pros is a trusted source of technical insight that helps tenant administrators stay informed and productive. We update the content every month to reflect changes across Microsoft 365 (including a complete book about Purview), and monthly update #137 is available now. Get your copy from Gumroad.com and stay up to date with the information that matters most for keeping your tenant secure, compliant, and running efficiently.