Why Basic Authentication requires Aplication Impersonation

When integrating Microsoft Exchange with the AskCody Platform using Basic authentication it requires Application Impersonation enabled. This article explains why.

AskCody accesses data in Microsoft Exchange (both on-premises versions and Exchange Online as part of Office 365) through Exchange Web Services (EWS) using either Basic Authentication or Modern Authentication.

These authentication methods either requires and uses the username and password of a Service Account created in Exchange and integrated through the AskCody Admin Center, or uses the widely used OAuth 2.0 protocol, which is more secure because Modern Authentication doesn’t require a service account, and therefore doesn’t involve a password that can be compromised.

Integrating AskCody with Microsoft Exchange using Basic Authentication, we need to make sure the used Service Account on the Microsoft Exchange Server (or Exchange Online) can create, edit, and delete meetings. This ability is done, by granting the Service Account the ApplicationImpersonation role. 

AskCody will use this permission granted to the Service Account to do things like end meetings early via the room display or remove abandoned events automatically, or simply to look up availability across the entire organizations meeting rooms, when using AskCody to search for available space.

ApplicationImpersonation allows the Service Account to manage events on behalf of your office's room resource calendars, regardless of who originally created the event, and gives you auditable logs for reference. ApplicationImpersonation is used in scenarios in which a single account needs to access many accounts, meaning line-of-business applications that work with mail or calendar events.

Understand Application Impersonation

Developers of applications that require access to user mailboxes often struggle with the choice between the Impersonation and Delegation access methods. While both provide programmatic rights to mailbox objects, they are designed to meet rather different needs, and for situations where a single account needs to access multiple mailboxes, Impersonation is the better choice. This article will provide an overview of why, and what the implications of using Impersonation are and why we at AskCody require Impersonation enabled for the service account. 

First, a point of clarification: Delegate access is geared to situations where an application needs access to mailbox items controlled by a user, and where it is likely that code will be run under the logged-on users' permissions. Accordingly, Delegate access is a user-manager permission, as it presumes that the user/owner of the mailbox is explicitly granting access.

Impersonation, on the other hand, has been designed to support enterprise applications and is an administratively controlled access methodology that requires no intervention from the mailbox owner. One way to think of the differences is that Impersonation is access for applications, whereas Delegated access is for users (like when your assistant needs to book a meeting on behalf of you).

In practice, applications using EWS Impersonation (like AskCody) are more robust, as other applications or normal users cannot revoke permission settings on the fly as they can with Delegate settings. Furthermore, the setup and administration of Impersonation are significantly less complex and time-consuming when dealing with large sets of users, as it can be set globally rather than per mailbox.

From a security perspective, Impersonation is also preferable to Delegate access (Only when using AskCody Services Add-in, Visitors Add-in, and Displays with advanced features) for the following reasons:

• Access via EWS is not available to end-users, and EWS calls can (and should) be secured on the wire via SSL. All data in motion from AskCody is encrypted using 128-bit TLS 1.2+.
• Role-based access permissions to enable or disable Impersonation rights are provisioned on the account level and can be set only via the Exchange administrator.
• Both Impersonation and Impersonation activity can be logged by both IIS and EWS native logging functionality, providing a full audit trail. This means that you will be able to log and monitor how the Service Account is being used and immediately be aware if you suspect abuse of data or access to user’s accounts.

To summarize some of the reasons why EWS Application Impersonation is considered the best approach to application-level mailbox access for server/service type applications and why AskCody need Impersonation to work accordingly:

• It is an administrator-managed, not user-managed permission, which means that a user or other application cannot change the permission settings.
• It is inherently designed for one-to-many mailbox access, which means there are less configuration complexity and overhead for managing new users that need to be added to the application scope.
• It takes advantage of EWS features, such as Throttling, that are designed to help manage application access to user mailbox data and needed for applications like AskCody to work. For example, impersonation accounts can have their own throttling budget (as of Exchange 2010 SP2), which means that applications using impersonation can’t inadvertently lock users out of their mailboxes for exceeding their budget. 
• It can be scoped to only be used through EWS, which means that users with access to an account with impersonation rights would need to write an EWS application to access a user’s mailbox and could not directly access the mailbox via a mailbox client such as OWA.

Audit logging and trails for the Service Account

If you suspect any abuse of the Impersonation role a full audit trail can be provided by both the IIS and EWS native logging functionality and by the Non-Owner Mailbox Access Report in Exchange Admin Center. Here we'll go a bit more into detail about the Non-Owner Mailbox Access Report. The Non-Owner Mailbox Access Report in the Exchange Administration Center (EAC) lists the mailboxes that have been accessed by someone other than the person who owns the mailbox. When a mailbox is accessed by a non-owner, Microsoft Exchange logs information about this action in a mailbox audit log that’s stored as an email message in a hidden folder in the mailbox being audited. Entries from this log are displayed as search results and include a list of mailboxes accessed by a non-owner, who accessed the mailbox and when, the actions performed by the non-owner, and whether the action was successful. By default, entries in the mailbox audit log are retained for 90 days. This can be changed to meet your needs. When you enable mailbox audit logging for a mailbox, Microsoft Exchange logs specific actions by non-owners, including both administrators and users, called delegated users, who have been assigned permissions to a mailbox. You can also narrow the search to users inside or outside your organization. To learn more about this please visit Technet. Mailbox activities performed by the mailbox owner, a delegated user, or an administrator are logged. By default, mailbox auditing in Office 365 isn’t turned on. Mailbox audit logging must be turned on for each mailbox before the mailbox activity will be logged. 

As of June 20th, 2018 you are also able to audit calendar delegation and inbox rules. This allows you to keep an eye on changes made to calendar delegation and inbox and this also lets you know who made the changes. 

To see a full list of Exchange Mailbox Activities that are logged by the mailbox audit logging, please go to Office 365 security compliance center 

ApplicationImpersonation is required to avoid throttling of EWS

ApplicationImpersonation is required to avoid throttling of EWS requests and accessing meeting. In normal use, the EWS requests are not done in large numbers, but during the initialization of notifications needed to get the full picture of the meeting, it can result in a larger number of requests that can cause throttling issues. With ApplicationImpersonation, Impersonation accounts can have their own throttling budget (as of Exchange 2010 SP2), which means that applications using impersonation can’t inadvertently lock the user’s out of their mailboxes for exceeding their budget.