Note: Microsoft has announced that RBAC using ApplicationImpersonation is being deprecated. As of May 2024, new assignments of the ApplicationImpersonation role will no longer be supported and the role will be appreciated at the end of 2025. To learn more about Microsoft's end of support for RBAC/ApplicationImpersonation please read this Microsoft article. |
When creating an OAuth connection to Office 365, follow these procedures in Microsoft Azure:
- Find the Directory ID.
- Create an App Registration.
- Grant Office 365 Exchange Online Permissions to the new App Registration.
- Limit the scope of mailboxes that the Riva app has access to
- Create the Connection in Riva.
Step a: Find the Directory ID
Applies to:
- Client secret-based OAuth connections to Office 365, and
- Client secret-based OAuth connections to Dynamics CRM.
To find the Directory ID:
-
In the Microsoft Azure Portal for your organization, navigate to Azure Active Directory and then to Properties.
-
On the Properties page, locate the Directory ID, and copy it.
It will be used as the Tenant ID in the connection.
Step b: Create an App Registration for an OAuth Connection
Applies to:
- Client secret-based OAuth connections to Office 365, and
- Client secret-based OAuth connections to Dynamics CRM.
To create an App Registration for the connection:
-
In the Microsoft Azure Portal for your organization, navigate to More s=Services.
-
In the All Services search field, search for App Registrations, and select App Registrations.
-
On the App registrations page that appears, select + New registration.
-
On the Register an application page appears,
set the following:-
Name: Enter a name that is unique among all the other application registrations in your organization's Azure portal.
-
Supported account types: Use the default option, Accounts in this organizational directory only (Single tenant).
-
Redirect URL (optional):
-
-
At the bottom of the page, select Register.
Result: An App Registration and its Application ID are created.
-
Locate the Application (client) ID, and copy it.
Note: It will be used as the Application ID in the connection.
-
For Office 365 connections, remain in this window for the next procedure.
Step c: Grant Office 365 Exchange Online Permissions to the New App Registration
To grant Office 365 Exchange Online permissions to the new Application Registration:
-
On the leftmost pane, select API Permissions. On the Configured permissions page that appears, select Add permission.
-
On the Request API permissions pane that appears to the right, select the APIs my organization uses.
-
In the search field, enter Office, and select Office 365 Exchange Online.
-
Select the required type of permissions:
-
For a client secret-based connection:
-
Select Delegated Permissions.
-
Under Select Permissions, expand EWS.
-
Select the check box to the left of EWS.AccessAsUser.All and Access mailboxes as the signed-in user via Exchange Web Services.
-
At the bottom of the pane, select Add Permissions.
-
Result: The rightmost pane disappears. The Configured Permissions page appears and displays the item that you added permissions to.
-
Select the app that you added permissions to, and then select Grant admin consent.
For an example, the screen shot displays a delegated permission.Note: The right pane, Request API permissions, reappears.
-
On the Office 365 login window that appears, log in as the same user as when you logged in to the Azure portal.
Result: You are brought back to the right pane, Request API Permissions.
-
Close the right pane.
Result: The Status column now displays "Granted for ...".
Step d: Limit the scope of mailboxes that the Riva app has access to
Depending on which use case applies to your organization, you may or may not need to add (assign) the users who will be using OAuth in the Riva connection to Office 365.
Use case | Description | Action to Take |
#1 | Impersonation is used - permissions are granted to a service account that is configured to have impersonation access to other mailboxes. | Procedure to configure Impersonation. |
#2 | Impersonation is not used — permissions are granted on an application level and the application is limited to access only a subset of user mailboxes. | Procedure to limit application access to specific mailboxes. |
For use case #2.
Organizations can limit access to mailboxes for all users.
-
Follow instructions from https://docs.microsoft.com/en-us/graph/auth-limit-mailbox-access to limit access to all users and provide access to some users to the application.
-
Recommendation: Add the subset of users in a security group in the Azure Application and add it to the -PolicyScopeGroupId arguments.
-
Note: Changes to application access policies can take longer than 1 hour to take effect, even when
Test-ApplicationAccessPolicy
shows positive results
-
Step e: Create the Connection in Riva
Do one of the following:
Use case | Description | Action to Take |
#1 | Impersonation is used - permissions are granted to a service account that is configured to have impersonation access to other mailboxes. | Create a client secret-based Office 365 OAuth connection: In Riva, enter the OAuth client secret-based connection details. |
#2 | Impersonation is not used — permissions are granted on an application level and the application is limited to access only a subset of user mailboxes. | Create a certificate-based OAuth connection to Office 365: In Riva, enter the OAuth certificate-based connection details |
- If creating a client secret-based Dynamics CRM OAuth connection: In Riva, enter the Tenant ID and Application ID in the Dynamics 365 OAuth Client Secret connection.