There has been a growing number of questions regarding how server-side synchronization (SSS) communicates between user mailboxes within Dynamics 365 apps (or Power Platform environments enabled with Dataverse) and their respective Microsoft Exchange mailboxes. This blog series is to help provide additional information to security teams which explains how the authentication is being done, methods to control communication, and how to monitor access of SSS to Exchange mailboxes.
Server-side synchronization (SSS) is a micro-service hosted within the Power Platform that provides direct apps-to-email server synchronization. It acts as a “man in the middle” service to connect Dataverse to Microsoft Exchange.
Connectivity and authentication
A common question that is asked, and is not covered in our Microsoft documentation, is how server-side synchronization (SSS) establishes connectivity and authentication between Dataverse and Microsoft Exchange Online.
By default, SSS communicates to Dataverse using Dataverse APIs and it communicates to Microsoft Exchange Online through Graph APIs. Before SSS can communicate between these two services, Dataverse mailboxes must be approved by a tenant user with one of the following combination of roles:
| ¤ |
Office 365 global admin & Dynamics 365 system admin |
| ¤ |
Exchange admin & Dynamics 365 system admin |
| ¤ |
Delegate Mailbox approver (Dynamics 365 role) & Dynamics 365 system admin |
| ¤ |
A user, no delegates, can self-approve their own mailbox if their UPN matches the email address in the mailbox record if they have the appropriate security role permissions. |
Additional information regarding these roles, necessary permissions, and the approval process can be found in the following document:
Approve email
This process gives additional oversight to ensure that users are not modifying their email address and allowing SSS to process the mailbox of a different Office 365/Exchange user. For example, if I was to change the email address of my Dataverse mailbox record to use Satya Nadella’s email address and an admin with the roles and permissions identified above approved the changes of my mailbox record, then SSS would process emails in Satya’s Exchange mailbox into Dataverse with me being the owner. This would, effectively, allow me to see Satya’s Exchange emails within Dataverse. Users who have the responsibility to approve mailboxes should ensure they firmly evaluate each mailbox approval for accuracy and consistency. Additionally, you could put in some automation to reject changes a user does to their mailbox record that is inconsistent with your business process. This is explained further below.
Once a Dataverse mailbox is approved and it is tested and enabled, SSS can now communicate between the two services. Since SSS is a micro-service of Dataverse, it already can connect to the Dataverse mailbox. However, to allow authentication between Dataverse with Microsoft Exchange, we must tell SSS how to connect to Microsoft Exchange. This is done via the email server profile in Dataverse.
By default, Dataverse creates an email server profile for Microsoft Exchange Online. This profile uses a first-party trust in the form of an Azure AD app registration for Dataverse. This app registration is not visible within a customer’s Azure AD app registrations because of the first-party nature. This means that one could not see what the settings or configuration are of this app registration. This is where this article hopes to provide more clarity. Below are some app registration configurations for SSS:
| ¤ |
Delegate or Application permissions |
| |
¤ Application permission |
| ¤ |
API |
| |
¤ Microsoft Graph |
| ¤ |
Consent |
| |
¤ Admin consent |
Need to understand more about Azure AD app registrations? The following articles, I felt, did a really good job explaining app registrations in more detail:
What access does SSS have to a user’s mailbox?
In order to process items in a user’s Exchange mailbox, SSS has full access to the various activities that are synchronized to Dataverse. Since the default Exchange Online profile uses Graph API, below are the different Graph API permissions SSS has access to with admin consent:
This wraps up the first article in this series and should provide a bit more clarity on how SSS connects with Microsoft Exchange Online. The other articles in this series help explain how to restrict and monitor SSS activity with Microsoft Exchange.
See the other articles of this blog series:
