Share via

Differentiating Access Control: Purview Role Groups vs. Microsoft Entra ID Roles (and App-Only Auth)

Niv BenSalmon 120 Reputation points
2025-11-26T09:02:12.9066667+00:00

Hey,

I am seeking clarification on the relationship and functional differences between role assignments managed in the Microsoft Purview portal and directory roles managed in the Microsoft Entra admin center (Azure Portal).

1. Purview Portal Role Assignment Scope (User Focus)

In the Microsoft Purview portal, under Settings > Roles and scopes, I can assign permissions via built-in Role Groups (e.g., Compliance Administrator, eDiscovery Manager). This portal seems primarily focused on granting access to User Principal identities (human users), typically identified by their UPN/Email. Can Service Principals (Enterprise Applications) be directly assigned to these Role Groups via the Purview portal UI? If not, is the assignment of a service principal limited to indirect methods (e.g., membership in a Security Group which is then assigned to the Role Group)?

2. Entra ID Role Assignment and Synchronization (User Impact)

  • In the Microsoft Entra admin center (Azure Portal), I can assign directory roles (e.g., Global Administrator, Security Administrator) to both Users and Applications.
    If I assign a high-privilege Microsoft Entra ID Role (e.g., Security Administrator) to a user in the Azure Portal, does this automatically confer membership or equivalent permissions in the corresponding Purview Role Group?
  • Is the Entra ID Directory Role the superior, tenant-wide permission layer, while the Purview Role Group is the service-specific permission layer?

3. Role Effectiveness and Best Practice

  • For a human administrator who needs access to all compliance features, which assignment method is considered the most affective and follows Microsoft's current security best practices (LPAC, PIM)?
    • Option 1: Assigning the Entra ID Compliance Administrator Role (Azure Portal).
    • Option 2: Assigning the Compliance Administrator Role Group (Purview Portal).
  • How does assigning a high-level Entra ID Role (e.g., Security Administrator) to the Service Principal (App) affect its ability to execute tasks that require Purview permissions (e.g., running PowerShell cmdlets via the Security & Compliance endpoint)?

I hope this questions are clear,
Thank you very much for the help!

Microsoft Security | Microsoft Purview
0 comments

Answer accepted by question author

Vasil Michev 127K Reputation points MVP Volunteer Moderator
2025-11-26T09:20:32.0166667+00:00

Generally speaking, if your scenario is primarily Purview focused, you should be using the Role Groups therein, especially if you are concerned about the principal of least privilege. While Entra role such as the Compliance administrator one do "map" against Purview Role Groups, they are much less granular in comparison. That said, the level of granularity/RBAC controls in Purview are a bit limited if compared to the Exchange Online RBAC story.

If you plan to leverage service principals, you can assign the corresponding Purview permissions via PowerShell, the UI does not currently support this (but will show already existing assignments to SPs). Here's a sample article that walks you over the process for the case of eDiscovery permissions: https://learn.microsoft.com/en-us/graph/security-ediscovery-appauthsetup

Was this answer helpful?

1 person found this answer helpful.
0 comments

Answer accepted by question author

AI answer

2025-11-26T09:02:27.7333333+00:00
  1. Purview Portal Role Assignment Scope: In the Microsoft Purview portal, role assignments are primarily focused on user principal identities (human users). Service Principals (Enterprise Applications) cannot be directly assigned to Role Groups via the Purview portal UI. Instead, they can only be assigned indirectly through membership in a Security Group that is then assigned to the Role Group.
  2. Entra ID Role Assignment and Synchronization: When a high-privilege Microsoft Entra ID Role (like Security Administrator) is assigned to a user in the Azure Portal, it does not automatically confer membership or equivalent permissions in the corresponding Purview Role Group. The Entra ID Directory Role acts as a tenant-wide permission layer, while the Purview Role Group serves as a service-specific permission layer.
  3. Role Effectiveness and Best Practice: For a human administrator needing access to all compliance features, the most effective method following Microsoft's security best practices (Least Privilege Access Control, Privileged Identity Management) would be to assign the Compliance Administrator Role Group in the Purview Portal (Option 2). Assigning a high-level Entra ID Role to a Service Principal (App) does not directly affect its ability to execute tasks requiring Purview permissions, as those permissions are managed separately within the Purview Role Groups.

In summary, it is essential to understand the distinctions between the role assignments in the Purview portal and the Entra ID roles to ensure proper access management and compliance.

AI-generated content may be incorrect. Read our transparency notes for more information.

Was this answer helpful?

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Niv BenSalmon 120 Reputation points
    2025-11-26T09:11:44.2833333+00:00

    I need to clarify a specific point regarding automation accounts and the statement: "Assigning a high-level Entra ID Role to a Service Principal (App) does not directly affect its ability to execute tasks requiring Purview permissions, as those permissions are managed separately within the Purview Role Groups."

    My core concern is whether App-Only Authentication can be used for compliance and security automation.

    I want to confirm: Can a Service Principal (Application) be granted the necessary permissions to execute specific, sensitive actions within the Microsoft Purview scope?

    For example, I want a dedicated Service Principal (which is the Enterprise Application object in Microsoft Entra ID) to be able to:

    Execute the PowerShell cmdlet New-TenantAllowBlockListItems.

    Perform automated eDiscovery Search Actions (e.g., via APIs or PowerShell).

    Is this capability limited only to a human administrator, or can it be achieved via a Service Principal?

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.