This guide explains why Planner and Display need impersonation rights in Exchange, how both solutions use the required permissions for accessing Exchange, and what logging options can be used for audit purposes.
Application Impersonation - Display - why?
Display requires application impersonation ONLY to room calendars to ensure proper synchronization of rooms booked and the appointments to which they are booked.
Limiting application impersonation to specific room calendars can be ensured using scoped permissions in Azure
- We can only access room calendar information
- We do not store calendar information per user
Application Impersonation - Planner - why?
Planner requires application impersonation on rooms and user calendars to ensure proper synchronization of rooms booked and the appointments to which they are booked.
If user "Allan" creates an appointment in Sign In Workspace (SiW), then SiW writes this appointment into user "Allan"s Outlook Calendar. For that, to work, SiW needs application impersonation permissions. The same happens when an appointment is updated, rescheduled, or deleted.
Without impersonation rights, SiW cannot ensure that the data in Outlook and in SiW is the same.
Application impersonation must-have application impersonation permissions on every user and every meeting room.
- We only access relevant calendar information
- We do not save attachments or meeting agendas for any calendar appointment related to a SiW meeting
- We do not access nor process users' mailbox items
How Application Impersonation is offered in different Exchanges
Depending on the Exchange - we require access using either an Azure Application or a service account
Azure / Exchange Online
For that to work with Azure, an application must be created with assigned application impersonation.
For older / on-premise Exchange, the permission is assigned a service account.
Why not use delegate permissions
Traffic via EWS is also limited to throttling limitation on EWS - and using application impersonation ensures that the requests from SiW aren't affected by this limitation.
This can not be ensured when using delete permissions and is for that reason not supported by SiW.
If you have concerns
With Office 365 mailbox auditing, logging can be enabled. This allows full insight into the events/actions performed, which can be used to audit for any suspect of abuse by the service account with application impersonation.
Please see the KB from Microsoft on this topic here https://support.office.com/en-us/article/Search-the-audit-log-in-the-Office-365-SecurityCompliance-Center-0d4d0f35-390b-4518-800e-0c7ec95e946c?ui=en-US&rs=enUS&ad=US&fromAR=1