Up to this point in the Security of Server-Side Synchronization blog series, we covered the different ways of managing server-side synchronization (SSS) with the default Microsoft Exchange Online server profile within Dataverse. However, this configuration has some limitations.
Organizations that require additional control of the actions and permissions for SSS should create a mail server profile using their own Azure AD app registration. This configuration is defined as cross-tenant but as mentioned in the previous articles, it is supported within the same tenant as well. The documentation for setting this up can be found here:
Exchange Online cross-tenant authentication
Ensure to change the mail server profile for your user mailboxes to use the one you created when setting this up within Dataverse:
Organizations that want to further restrict the scope of mailboxes that SSS can access should consider using Exchange application access policies along with their Azure AD App registration. By defining a security group of only mailboxes that should be processed by SSS, you limit the exposure of potentially sensitive inboxes being incorrectly configured and processed by SSS. The following article covers creating an application access policy in detail:
Limiting application permissions to specific Exchange Online mailboxes
 |
NOTE: After configuring an application access policy, it does take some time before the policy actually takes effect. |
Role-Based Access Control for Applications
Another option that can be used to help limit the scope of Exchange mailbox access is to use Role Based Access Control (RBAC) for Applications. Currently, this feature is in preview, but it will, eventually, replace Application Access Policies.
Additional details for Role Based Access Control for Applications can be found in the following article:
Role Based Access Control for Applications in Exchange Online
Caveats
There is a known issue with using this configuration for cross-tenant support. The cross-tenant server profile actually changes how SSS communicates with Microsoft Exchange. When using the default Exchange Online profile, SSS connects to a user’s mailbox via Microsoft Graph API. However, with the cross-tenant server profile, instead of using Graph API, SSS uses Exchange Web Services (EWS). Due to this, the Exchange manifest file used to create the App for Outlook application within Outlook fails to deploy. This is currently being investigated on how we can support this particular scenario. For more information about deploying the App for Outlook application, please review this document:
Deploy and install Dynamics 365 App for Outlook
 |
IMPORTANT: Cross-tenant configuration between multiple tenants does not support Dynamics 365 App for Outlook. Supportability is only for this configuration within the same tenant. |
Through the series of these articles, you should now understand how server-side synchronization (SSS) connects and authenticates to a Dynamics 365/Dataverse user’s Exchange mailbox and different configurations to limit the exposure of unexpected processing of an Exchange mailbox.
See the other articles of this blog series:
