Microsoft Purview Login: The Two-Plane Auth Problem and How to Solve It

Two Identity Planes, One Login Failure

You log in at purview.microsoft.com with a Global Admin account and see an empty catalog. No collections. No data sources. No scan results. The authentication worked. The authorization didn't.

Microsoft Purview splits identity across two planes that operate independently. Plane one is Entra ID (formerly Azure Active Directory): it controls who can see and manage the Purview resource in the Azure portal, assign Azure RBAC roles, and view billing. Plane two is the Purview Collection hierarchy: it controls who can read the data catalog, register data sources, and run scans. Being a Subscription Owner or even Global Admin gets you past the login page and into the resource blade. It does not get you into the catalog.

We have seen this trip up every team that touches Purview for the first time. The fix is a handful of role assignments, but knowing which assignments and where to make them is the entire problem.

What the Login Surface Actually Is

The unified portal since the 2022 rebrand is purview.microsoft.com. The legacy experience at portal.azure.com still exists for resource management, but catalog browsing, scanning, and governance workflows all live at the new URL.

Authentication at that URL goes through Entra ID with standard OIDC. Multi-factor enforcement, Conditional Access policies, and Privileged Identity Management all apply in the usual way. A user whose Entra ID sign-in gets blocked by a Conditional Access policy requiring a compliant device receives a generic "You don't have access" error with no indication that the block came from Conditional Access rather than a missing catalog role. We cover how to tell those apart below.

After Entra authenticates the session, Purview checks the user's position in the Collection hierarchy. Root collection membership with at least the Data Reader role is the minimum gate. Without it, the user lands on an empty portal every time, regardless of what Azure RBAC says.

The Collection Role Assignments That Matter

Purview's catalog has its own RBAC layer separate from Azure RBAC. The four roles that matter in practice:

| Role | What it unlocks | |---|---| | Collection Admin | Manage sub-collections, assign roles, register credentials | | Data Source Administrator | Register and manage data sources for scanning | | Data Curator | Create and edit catalog assets, apply classifications | | Data Reader | Browse assets, view classifications, read lineage |

These roles are assigned at a collection level and apply downward through child collections. A user assigned Data Curator on a child collection cannot see assets in sibling or parent collections unless they also hold a role there. The hierarchy is additive going down; it does not propagate upward.

To assign someone to the root collection, navigate to purview.microsoft.com, open Data Map, select Collections, choose the root collection, then open the Role Assignments tab. The person making that assignment must already hold Collection Admin on the root. In a brand-new tenant, the identity that created the Purview resource automatically receives that seed role.

Service Principal Auth for Automated Scanning

Automated scans, pipeline-driven catalog updates, and CI/CD integrations should authenticate with a service principal, not a user account. Here is the setup:

# 1. Create the service principal
az ad sp create-for-rbac \
  --name "sp-purview-scanner" \
  --skip-assignment \
  --output json

# Capture appId, password (client secret), and tenant from output.
# Store the secret in Key Vault immediately, it will not be shown again.

az keyvault secret set \
  --vault-name "<your-kv-name>" \
  --name "purview-scanner-secret" \
  --value "<client-secret-from-above>"

# 2. Assign the Azure resource-level role so the SP can call the Purview management plane.
# The catalog-level Collection role assignment must be done separately in the Purview portal
# or via the Purview management REST API under /collections/{collectionName}/listAssignedRoles.

az role assignment create \
  --assignee "<sp-app-id>" \
  --role "Purview Data Source Administrator" \
  --scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Purview/accounts/<account-name>"

# 3. Rotate the secret on a schedule, 90-day max.
#    Pull it at scan runtime from Key Vault rather than baking it into a config file.
az keyvault secret set-attributes \
  --vault-name "<your-kv-name>" \
  --name "purview-scanner-secret" \
  --expires "$(date -u -v+90d '+%Y-%m-%dT%H:%M:%SZ')"

Managed Identity is the cleaner option when the scanner runs on an Azure-native resource: Azure Data Factory, an Azure Function, or a VM. Assign the Managed Identity the same collection-level roles you would give a service principal. No secret rotation required. No credential stored anywhere.

For scanners running on AWS or on-premises infrastructure, the service principal path is the only option. That makes the Key Vault rotation policy non-negotiable.

Conditional Access Blocks That Look Like Catalog Errors

A Conditional Access policy requiring a compliant device, a managed network, or a specific authentication strength will block a Purview session and surface an error visually identical to a missing collection role. The user sees: "You don't have access to the Microsoft Purview governance portal."

The fastest way to tell the difference: open Entra ID Sign-In Logs in the Azure portal under Microsoft Entra ID > Monitoring > Sign-In Logs, filter by the user and the application "Microsoft Purview" or "Microsoft Azure." A Conditional Access block shows up as a failed sign-in with the policy name in the Conditional Access column. A missing collection role shows up as a successful sign-in, then a 403-equivalent from inside Purview's own audit trail.

If the block is legitimate policy enforcement, the user needs to satisfy the policy or request a PIM exception. If it is an accidental over-broad policy scope, the Conditional Access rule needs narrowing. Either way, diagnosing the plane of failure correctly saves time chasing phantom role assignments.

One pattern we see repeatedly: a Conditional Access policy scoped to "All cloud apps" includes Purview unexpectedly. Adding a named exclusion for the Purview application registration is the targeted fix, rather than carving out the user entirely.

Auditing Purview Sessions with KQL in Sentinel

Purview diagnostic logs flow into Log Analytics when you enable the audit diagnostic setting on the Purview resource. Entra ID sign-in logs flow there separately under the same workspace. Together they cover both failure planes.

// Plane 1: Entra ID sign-in failures for Purview sessions
SigninLogs
| where AppDisplayName has "Purview"
| where ResultType != "0"
| project
    TimeGenerated,
    UserPrincipalName,
    ResultDescription,
    ConditionalAccessStatus,
    IPAddress,
    DeviceDetail
| order by TimeGenerated desc

// Plane 2: Purview audit operations (catalog-level authorization and scan events)
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.PURVIEW"
| where OperationName has_any ("DataAsset", "Collection", "Scan", "RoleAssignment")
| project
    TimeGenerated,
    identity_s,
    CallerIpAddress,
    OperationName,
    ResultType,
    ResultDescription
| order by TimeGenerated desc

Running both queries side by side reveals the complete picture. A service principal showing repeated Entra failures is a credential rotation gap or an active credential compromise. A service principal with successful Entra sign-ins but consistent Purview 403s points to a collection role assignment that was never made, or was made on the wrong collection level.

Tying the second query into a Sentinel analytics rule with a threshold alert gives early warning when a scanner account degrades silently. That kind of detection fits directly into the pipeline we build for clients on our detection engineering practice.

When to Call Us

If you need Purview authentication designed for a multi-subscription estate, Conditional Access policy scoping, Sentinel integration for catalog audit events, or Collection hierarchy planning that maps to your data domain structure, reach out at /contact.