Application impersonation towards MS Exchange for Sign In Workspace

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.

Data Accessed:

• 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.

Example

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.

Data accessed

• 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.

On-premise Exchange

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