Service Principal Getting 403 "Not Authorized to Access Account" Error When Calling Purview Unified Catalog Governance Policies API

Question

Hi Microsoft Community,

We are implementing automation for managing governance domain roles in Microsoft Purview using the Unified Catalog REST API (GA version, October 2025). Our service principal can successfully authenticate and obtain tokens, but receives a 403 Unauthorized error when attempting to list governance policies.

Environment Details

• API Endpoint: https://api.purview-service.microsoft.com
• API Version: 2025-09-15-preview
• Operation: GET /datagovernance/catalog/policies
• Authentication Scope: https://purview.azure.net/.default
• Service Principal: Successfully obtains OAuth token using client credentials flow

Error Details

Status Code: 403

Error Response: {

"error": {

"code": "Unauthorized",

"message": "Not authorized to access account"

}

}

What We've Tried

1. ✅ Verified Authentication: Service principal successfully obtains access token for https://purview.azure.net scope
2. ✅ Added Collection Admin Role: Service principal added as Collection Admin on the root collection in Purview Governance Portal (Data Map → Collections → Root → Role assignments)
3. ✅ Added Data Curator Role: Also assigned Data Curator role at root collection level
4. ⏱️ Waited for Propagation: Waited 15+ minutes after role assignment
5. ✅ Verified Service Principal: Confirmed the service principal's Client ID matches what was added in Purview portal

Our Understanding

Based on Microsoft documentation:

• Collection Admin at root collection should grant access to manage governance policies across all domains
• The API endpoint and OAuth scope are correct per official documentation
• Token generation succeeds (401 would indicate auth failure, but we're getting 403 authorization failure)

What We've Tried

1. ✅ Verified Authentication: Service principal successfully obtains access token for https://purview.azure.net scope
2. ✅ Added Collection Admin Role: Service principal added as Collection Admin on the root collection in Purview Governance Portal (Data Map → Collections → Root → Role assignments)
3. ✅ Added Data Curator Role: Also assigned Data Curator role at root collection level
4. ⏱️ Waited for Propagation: Waited 15+ minutes after role assignment
5. ✅ Verified Service Principal: Confirmed the service principal's Client ID matches what was added in Purview portal

Questions

Is Collection Admin at root collection sufficient for calling GET /datagovernance/catalog/policies? Or are additional roles/permissions required?

Are there Azure RBAC roles (on the Purview account resource itself) needed in addition to Purview collection roles? We don't see "Purview Data Curator" as an Azure RBAC role - only in Purview's internal role system.

Does the Unified Catalog API require different permissions than what's documented for interactive portal access?

How long does role propagation typically take for Purview collection role assignments? We've waited 15+ minutes.

Is there a way to verify/troubleshoot which permissions the service principal currently has in Purview?

API Documentation Reference

• Purview Unified Catalog Policies - List
• Purview Catalog Permissions

Any guidance on the correct role configuration for API-based governance policy management would be greatly appreciated.

Answer 1

Hi Vishal Goud Kanakamamidi,

Thank you for sharing the detailed background and the steps you’ve already taken. Based on the information provided, your understanding is correct up to a point, and the behavior you are seeing (403 – Not authorized to access account) is consistent with a missing permission outside of the Purview collection roles.
Why this is happening

Although your service principal can successfully authenticate and obtain an access token, authentication alone does not guarantee authorization for Microsoft Purview Unified Catalog Governance APIs.

Microsoft Purview uses a two‑layer permission model:

1. Azure RBAC (control plane) – governs access to the Purview account resource
2. Purview collection roles (data plane) – govern actions inside the catalog (collections, domains, governance policies)

For Unified Catalog Governance REST APIs (such as GET /datagovernance/catalog/policies), both layers are required when using a service principal.

In your scenario:

• Collection Admin + Data Curator roles at the root collection
• Azure RBAC on the Purview account resource(missing)

When Azure RBAC is not present, the request reaches the service but is blocked at the account boundary, resulting in the 403 authorization error you observed.
What needs to be added

Please assign an Azure RBAC role to the service principal directly on the Microsoft Purview account in the Azure portal.

Recommended roles:

• Contributor (recommended)
• Owner (if broader permissions are acceptable)

This role assignment allows the service principal to access the Purview account itself, after which the already‑assigned collection roles are evaluated for the specific action.

After assigning the role, allow sufficient time for permission propagation before retrying the API call.

Answers to your specific questions

• Is Collection Admin at root collection sufficient for the Unified Catalog Governance API? No. Collection roles control catalog‑level operations but do not grant access to the Purview account for REST APIs when using a service principal.
• Are Azure RBAC roles required in addition to Purview roles? Yes. Azure RBAC is mandatory for service principals calling Unified Catalog Governance APIs.
• Is “Data Curator” an Azure RBAC role? No. It is a Purview‑internal role only and does not replace Azure RBAC.
• Does portal access differ from API access? Yes. Interactive portal access may work with collection roles alone, but REST APIs enforce Azure RBAC checks.
• How long does propagation take? Azure RBAC changes can take up to 30 minutes to fully propagate. Conclusion
  Your configuration inside the Purview portal is correct, but collection roles alone are not sufficient for Unified Catalog Governance APIs when using a service principal. Once Azure RBAC (Contributor or Owner) is assigned to the service principal at the Purview account level and permissions are fully propagated, the 403 error will be resolved and the API call will succeed
  Microsoft reference documentation
• https://learn.microsoft.com/azure/purview/security-access-control-overview
• https://learn.microsoft.com/azure/purview/catalog-permissions#azure-rbac-roles-for-purview
• https://learn.microsoft.com/purview/purview-permissions
• Microsoft Q&A – Service principal 403 “Not authorized to access account.

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

Answer 2

Hi ,

Thanks for reaching out to Microsoft Q&A.

Short answer: your setup is almost correct, but collection roles alone are not sufficient for this API.

Your issue is not authentication but missing account-level authorization. For the UC governance APIs, collection roles like Collection Admin or Data Curator are not sufficient. You must also assign an Azure RBAC role (such as Contributor or Owner) on the Purview account resource itself. The API checks RBAC first, especially for service principals, which is why you are getting a 403. Add the RBAC role, wait for propagation (up to 15 to 30 minutes), and retry; this typically resolves the error.

 

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.