Resolving 403 Forbidden Errors with Microsoft Modern Exchange Connector (Graph) or EWS

David Legault
David Legault
  • Updated

Overview

A 403 Forbidden error indicates that the client is authenticated but not authorized to access the requested resource. This is a common error when using Microsoft Modern Exchange Connector (Graph) or Exchange Web Services (EWS) if permissions, roles, or policies are misconfigured.

Symptoms

  • HTTP 403 response from Graph API or EWS requests.
  • Error messages may include:
    • Access is denied.
    • Insufficient privileges to complete the operation.
    • Forbidden – Authorization failed.
    • The request failed. The remote server returned an error: (403) Forbidden.(EWS)

Common Causes

Cause Description
Missing API permissions The app lacks required delegated or application permissions for Graph or EWS.
Admin consent not granted Required application permissions have not been approved by an admin.
Conditional Access policies Azure AD Conditional Access or Defender policies are restricting access.
Role-based access control (RBAC) The app or user lacks the required Azure roles or mailbox-level access.
Token issues The token is expired, improperly scoped, or issued for the wrong resource.
Blocked legacy authentication EWS access is blocked due to Basic Auth deprecation or policy enforcement.
Licensing The user doesn't have a valid Microsoft 365 license for the service.

Troubleshooting Steps

1. Verify API Permissions

Microsoft Graph

  • Identify required permissions using the Microsoft Graph permissions reference.

  • Confirm that the app registration includes the correct type of permissions:

    • Application – for app-only (non-interactive) access.

Exchange Web Services (EWS)

  • Riva supports only application permissions, specifically:

    • full_access_as_app is required when no RBAC scope is defined.

  • Delegate permissions are not supported, and Application Impersonation is deprecated in modern Exchange Online.

Note: Riva does not support EWS delegate permissions. Microsoft has deprecated Application Impersonation for OAuth-based access.

Additional Note: The full_access_as_app permission is only required if you are not using an RBAC scope. If your environment is scoped using RBAC for Application, follow Riva's internal documentation on RBAC scoping for proper configuration.

In Azure Portal:

  • Go to Azure Active Directory > App registrations > [Your App] > API permissions.

  • Confirm that full_access_as_app is listed under Application permissions (if applicable).

  • Ensure admin consent has been granted.

2. Confirm Access Scope (EWS and Graph)

Microsoft provides two models for scoping mailbox access when using application permissions:

  • RBAC for Applications (Recommended)

  • Application Access Policies (Legacy)

If using RBAC for Applications (Recommended)

RBAC for Applications is the modern and preferred way to restrict mailbox access for applications using EWS.

Note: Microsoft recommends using RBAC for Applications: "This feature extends the current RBAC model in Exchange Online and it replaces Application Access Policies."
Microsoft documentation

Role Assignment (used by Riva):

To assign RBAC scope to an app:

powershell

New-ManagementRoleAssignment -Name "RBAC RivaSync" -Role "Application EWS.AccessAsApp" -App a3324834-eacd-4f3a-8256-7d977a799ffe -CustomResourceScope "RivaSync"

  • -App is the client ID of the Azure AD application.

  • -CustomResourceScope refers to a management scope that defines which mailboxes the app can access.

To verify that the app has the correct role assigned

powershell

Get-ManagementRoleAssignment -Role "Application EWS.AccessAsApp" -App a3324834-eacd-4f3a-8256-7d977a799ffe | Format-List

  • This returns the current role assignment(s) associated with the application.

To test access to a specific mailbox:

powershell

Test-ServicePrincipalAuthorization -Identity "RBAC RivaSync" -Resource HenriettaM@rivalabs.onmicrosoft.com | Format-Table
  • Replace "RBAC RivaSync" with the name of the role assignment.
  • Replace the resource email with the target mailbox 

If using Application Access Policies (Legacy)

Application Access Policies allow mailbox-level restrictions when using the full_access_as_app permission.

To view existing policies:

powershell

Get-ApplicationAccessPolicy

To test mailbox access:

powershell

Test-ApplicationAccessPolicy -Identity user@domain.com -AppId <your-app-client-id>

3. Check Conditional Access and Security Policies

  • In Azure AD Portal, go to:

    • Azure AD > Security > Conditional Access

  • Review policies that might block access based on:

    • Location

    • Client app type (e.g., legacy vs. modern authentication)

  • Temporarily disable restrictive policies during testing, if possible.

Best Practices

  • Follow the principle of least privilege when assigning permissions.
  • Use Microsoft Graph Explorer or EWS Editor for controlled testing.
  • Implement robust error logging to capture and analyze 403 responses.
  • Regularly review and audit application and user access.

References

 

Related to