Restricting App Access using RBAC for Applications (Graph API)

By default, granting application permissions gives your Microsoft Entra application access to all mailboxes within your tenant. To follow the principle of least privilege, Microsoft recommends using Exchange Online Role-Based Access Control (RBAC) for Applications.

This method restricts the application's access strictly to users within a designated Mail-Enabled Security Group, preventing the connector from interacting with unauthorized mailboxes. Additionally, by assigning specific RBAC roles, you can also control which data types the application can access — for example, allowing calendar sync while blocking contacts.

Pre-requirements

Before applying these advanced restrictions, ensure you have already registered your application. To review the base setup process, refer to the Configuring Microsoft 365 (Graph API) article.

Warning: Broad permissions must be removed

Before proceeding, ensure that broad permissions (Calendars.ReadWrite and Contacts.ReadWrite) are removed from your App Registration in Microsoft Entra ID. Only User.Read.All must remain. If these broad permissions remain active, RBAC restrictions will have no effect — they work in addition to, not instead of, existing permissions.

Note: All commands in this guide must be executed in PowerShell with Administrator privileges. Also ensure you have the necessary Exchange Online administrative rights before proceeding.

Step 1. Connect to Exchange Online

First, import the required module and authenticate with your Microsoft 365 tenant:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

Step 2. Create a Service Principal

Link your existing Microsoft Entra application to Exchange Online by creating a Service Principal:

New-ServicePrincipal `
-AppId "your-app-id" `
-ServiceId "your-enterprise-app-object-id" `
-DisplayName "Your App Name"

Warning: Object ID vs. App ID

The -ServiceId parameter requires the Object ID from Enterprise Applications, not the Object ID from App Registration — these are different values for the same application.

Use one of the options below to find the correct ID before running the command above.

How to get the Object ID

Option 1 — Azure Portal:

Navigate to Enterprise Applications > [Your App Name] > Overview and copy the Object ID.

Use the ObjectId value in the New-ServicePrincipal command above.

Option 2 — PowerShell (if you don't have access to Azure Portal):

Run this command after connecting to Exchange Online:

Get-ServicePrincipal | Where-Object { $_.AppId -eq "your-app-id" } | Format-List DisplayName, AppId, ObjectId

Use the returned ObjectId value in the New-ServicePrincipal command above.

Step 3. Create a Mail-Enabled Security Group

Warning: Group Type Restriction

The group must explicitly be a Mail-Enabled Security Group. Standard Microsoft 365 or Entra ID groups are not supported for this policy.

Create a Mail-Enabled Security Group:

New-DistributionGroup -Name "Sendent RBAC Group" -Alias "sendentrbacgroup" -Type Security

Step 4. Add Users to the Group

Add the specific users whose data will be synchronized by the connector:

$users = "user1@domain.com", "user2@domain.com"
foreach ($user in $users) {
Add-DistributionGroupMember -Identity "sendentrbacgroup@domain.onmicrosoft.com" -Member $user
}

Step 5. Assign RBAC Roles

Warning: Remove broad permissions from App Registration

If your App Registration has Calendars.ReadWriteand Contacts.ReadWrite permissions configured, you must remove them before assigning RBAC roles:

  1. Go to Azure Portal > Entra ID > App registrations > [Your App Name] > API permissions

  2. Remove Calendars.ReadWrite and Contacts.ReadWrite

  3. If they appear in the "Other permissions granted" section — click ...Revoke admin consent

After this, RBAC roles become the sole mechanism controlling mailbox access.

You must assign specific RBAC roles to your Service Principal, scoping them exclusively to the group you created:

For Calendars:

New-ManagementRoleAssignment `
-App "your-enterprise-app-object-id" `
-Role "Application Calendars.ReadWrite" `
-RecipientGroupScope "sendentrbacgroup@domain.onmicrosoft.com"

For Contacts:

New-ManagementRoleAssignment `
-App "your-enterprise-app-object-id" `
-Role "Application Contacts.ReadWrite" `
-RecipientGroupScope "sendentrbacgroup@domain.onmicrosoft.com"

Note: Restricting Access by Data Type
If you want to restrict access to specific data types — for example, allow only calendars and block contacts — simply assign only the relevant role.

To remove an existing role assignment, use the Remove-ManagementRoleAssignment command from the Additional Management Commands section.

Step 6. Verify and Test the Policy

To confirm the roles were assigned successfully, retrieve them using your Enterprise App Object ID:

Get-ManagementRoleAssignment | Where-Object { $_.App -eq "your-enterprise-app-object-id" } | Format-List Role, CustomResourceScope

Important Considerations

  • Propagation Delay: After assigning roles, you must wait 10 to 30 minutes for the changes to fully propagate and take effect.

  • Visualizing the Group: You can visually confirm the group's members by navigating to the Azure Portal: Entra ID > Groups > [Search for your group] > Members

  • Multiple groups with different data types: You can create multiple groups on the same App Registration, each with different RBAC roles.

Additional Management Commands

Here are a few supplementary PowerShell commands to help you manage your group and roles over time:

Check who is in the group:

Get-DistributionGroupMember -Identity "sendentrbacgroup@domain.onmicrosoft.com"

Remove a user from the group:

Remove-DistributionGroupMember -Identity "sendentrbacgroup@domain.onmicrosoft.com" -Member "user@domain.com" -Confirm:$false

Delete the entire group:

Remove-DistributionGroup -Identity "sendentrbacgroup@domain.onmicrosoft.com" -Confirm:$false

Warning: Deleting and Recreating Groups

If you need to delete a group and create a new one, always remove the associated role assignments before deleting the group. If you delete the group without removing the role assignments first, the assignments will remain in Exchange Online without a scope, granting broad access to all mailboxes.

Use the Remove a specific role assignment command from the Additional Management Commands section before deleting the group.

Find all assigned roles by name and role:

Get-ManagementRoleAssignment | Where-Object { $_.App -eq "your-enterprise-app-object-id" } | Format-List Name, Role

Remove a specific role assignment:

Remove-ManagementRoleAssignment -Identity "Role Assignment Name here" -Confirm:$false


Was this article helpful?