Loading

Configuring Einstein Activity Capture with Microsoft Graph API and RBAC.

Date de publication: Feb 2, 2026
Description

This document details some of the PowerShell steps that can be used to implement Exchange Role-Based Access Control (RBAC) for an Azure Application, enabling granular control over mailbox access. This is a guide to the process as various paths can be taken here to segment groups and set permissions. For details see this article and work your Microsoft support contacts

Résolution

Prerequisites and Useful Links

Using Exchange RBAC for Applications

Exchange RBAC allows you to dynamically add object scopes (permissions) to an application's access token when targeting specific mailboxes, providing fine-grained control that is superior to legacy EWS methods.

Note: RBAC can add permissions; it cannot dynamically remove scopes that were granted during initial application consent. Configuration currently requires PowerShell.

Step 1: Create a Service Principal

This step registers the application and its unique identifiers within Exchange Online. This must be done once per Azure tenant.

PowerShell Command:

New-ServicePrincipal -AppId xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -ObjectId dd147429-bf6d-4562-b12b-b05c580c1c82 -DisplayName "Einstein Activity Capture"

 

Step 2: Define a Management Scope

A Management Scope groups the target users (mailboxes) using a RecipientRestrictionFilter based on user attributes (e.g., CustomAttribute1, Department).


Example A: Grouping by Custom Attribute The scope "EAC" targets mailboxes where CustomAttribute1 equals 'EAC_CEM'.

PowerShell Command: New-ManagementScope -Name "EAC" -RecipientRestrictionFilter "CustomAttribute1 -eq 'EAC_CEM'"


Example B: Grouping by Department The scope "RBAC Users Department" targets mailboxes where the Department equals 'RBAC Users'.

PowerShell Command:  New-ManagementScope -Name "RBAC Users Department" -RecipientRestrictionFilter "Department -eq 'RBAC Users'"


Step 3: Management Role Assignment (Adding Scopes)
This step links the Application (using the Object ID), the desired Graph API Role (prefixed with Application), and the Management Scope (defined in Step 2).

Role Assignments for Full Access to "EAC" Scope These commands grant Read, Write, and Send permissions for Contacts, Calendars, and Mail to the Service Principal, limited only to users in the "EAC" scope.

PowerShell Command: 
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Mail.Send" -CustomResourceScope "EAC"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Mail.Read" -CustomResourceScope "EAC"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Calendars.ReadWrite" -CustomResourceScope "EAC"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Calendars.Read" -CustomResourceScope "EAC"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Contacts.ReadWrite" -CustomResourceScope "EAC"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Contacts.Read" -CustomResourceScope "EAC"

Alternative: Limited Access for "RBAC Users Department" Scope This grants only Calendar and Contacts Read/Write access to users in the specified department, excluding Mail.

PowerShell Command: 
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Calendars.ReadWrite" -CustomResourceScope "RBAC Users Department"
New-ManagementRoleAssignment -App dd147429-bf6d-4562-b12b-b05c580c1c82 -Role "Application Contacts.ReadWrite" -CustomResourceScope "RBAC Users Department"


Step 4: Testing Authorization
Use the Test-ServicePrincipalAuthorization cmdlet to confirm which roles have been successfully applied to a specific user via the RBAC configuration.

PowerShell Command: 
Test-ServicePrincipalAuthorization -Identity "Einstein Activity Capture" -Resource [user-email-address]

Important Note: Access changes via the Graph API may take a significant amount of time (e.g., 30 minutes or more) to propagate and take effect, even if the test command returns positive results immediately.

Key Points to Add to Public Documentation

  • Custom claims are not supported in the Exchange Admin Center (EAC) Graph API RBAC application configuration. Any manually added claims in Azure AD / Entra ID for this app should be removed.

  • Modifying or adding claims does not resolve UPN vs. primary SMTP address differences. Aligning these values is not required for the EAC Graph API integration.

  • UPN and primary Exchange email address mismatches only affect user-level connected mailbox scenarios and do not impact organization-level authentication, which is the only authentication model supported for the EAC Graph API beta/pilot.

  • Guidance suggesting the alignment of UPN and primary email via custom claims is incorrect for this feature. Customers should maintain their existing identity configuration unless they are specifically troubleshooting user mailbox authentication in other applications.

  • The EAC Graph API beta/pilot currently supports only org-level OAuth authentication, meaning no user impersonation or per-user authentication workflows are in scope.

Ressources supplémentaires

Note: The example provided is for reference purposes only. Any configuration or setup required in Microsoft Azure or Entra ID, including application registration, permissions, or scope assignments is managed by the domains Microsoft administrator.
Salesforce does not configure or support Azure-side components. Customers should follow Microsoft’s official documentation when performing these steps.

Numéro d’article de la base de connaissances

005228035

 
Chargement
Salesforce Help | Article