Exchange Impersonation vs. Delegate Access

There has been some confusion about the different methods that can be used to access a mailbox. Developers are asking: What method should I use? When should I use it? What are the differences between the different methods? This post will give you a quick comparison of the two most common ways, other than a direct log on, to access a mailbox: Exchange Impersonation and delegate access.

Exchange Impersonation vs. Delegate Access

Exchange Impersonation is used in scenarios in which a single account needs to access many accounts. Line-of-business applications that work with mail typically use Exchange Impersonation. An application can be written to display mailbox data such as number of unread items, calendar, and so on. The application can use a dedicated service account to access multiple users’ mailboxes to display their respective data.

Exchange Impersonation is different than Windows Impersonation. Windows Impersonation is an operating system concept that requires you to set Kerberos constrained delegation. Exchange Impersonation is a simpler authorization mechanism that is designed for use only within Exchange Web Services (EWS). For more information about Windows Impersonation, see Client Impersonation on MSDN.

Delegate access is used in scenarios in which there needs to be a one-to-one relationship between users. One common application of delegate access is the sharing of calendars between users, such as when an admin manages an executive’s calendar, or a when handful of individuals working on a project need to coordinate calendars.

Another example of delegate access is resource mailbox management. Resources, such as conference rooms, can be managed by one or more people. Resources are represented by mailboxes, but not in the traditional sense. Resource mailboxes do not have owners; therefore, they can only be accessed by mail-enabled users to whom delegate access is granted.

The following table lists the differences between Exchange Impersonation and delegate access.

	Exchange Impersonation	Delegate Access
Administered by	Administrator	User
Used by	Exchange Web Services	Any mailbox client
Configuration	Per impersonator	Per shared mailbox
Rights	Broad	Granular
New account creation	Can be automated	ACLs stamped

Administration

An administrator is able to configure impersonation on behalf of a service account, and grant that service account impersonation rights over many mailboxes. Individual users cannot manage who does or does not have impersonation rights over their mailboxes.

Individual users can grant and remove delegate access to their own mailboxes through several mailbox clients, such as Microsoft Outlook, Outlook Web Access, or Exchange Web Services-based clients. A mailbox owner does not need administrator rights to grant another user delegate access to their mailbox.

Auditing

There is no true auditing for either Exchange Impersonation or delegate access. Any mail that is modified by using impersonation will appear to the mailbox as if it was modified by the user who was impersonated. No log is left behind of the impersonation access.

^†For delegate access, there is partial auditing, in that any mail that is sent by a delegate on behalf of the mailbox owner is displayed as “Sent on behalf of.”

Usage

Exchange Impersonation can only be used through Exchange Web Services. The caller (authenticated user) indicates which user they want to impersonate in the SOAP header. For more information about how to use Exchange Impersonation, see Using Exchange Impersonation on MSDN.

Delegate access can be used through any mailbox client, including Outlook and Exchange Web Services-based clients. For more information about delegate access, see Exchange Web Services and Delegate Access on MSDN.

Rights

A user or account that has been granted impersonation rights will have the same rights as the user whom they are impersonating. Typically, service accounts are given the ability to impersonate the mailbox owner. In that case, the impersonating account has full mailbox rights, just as the mailbox owner does.

With delegate access, the delegate can be granted more granular rights, up to and including full mailbox access. Delegate access can also be configured per folder, or per mailbox. For example, a user can grant the delegate read-only access to the Inbox, read-write access to a calendar folder, and so on.

Configuration

Exchange Impersonation is generally configured as one-to-many: one service account to many user accounts. You can configure an account to impersonate a broad set of users, such as an entire mailbox database. For more information about how to configure impersonation, see Configuring Exchange Impersonation on MSDN.

For delegate access, there is no option to set up a single delegate for multiple mailboxes. A relationship must be established for each user who needs to access a given mailbox.

New Accounts

You can configure Exchange Impersonation to allow new accounts that are created to automatically be impersonated by service accounts. Setting up accounts to impersonate any user within a mailbox database can reduce your configuration overhead.

You must explicitly grant delegate access for any new users who are added.

Comments

• Anonymous
  June 15, 2009
  PingBack from http://www.ditii.com/2009/06/16/explaining-exchange-impersonation-vs-delegate-access/

• Anonymous
  June 16, 2009
  The Exchange API team has a new post to explaining the differences between using Exchange Impersonation

• Anonymous
  July 13, 2009
  When is this change coming? Ex 2010?  Impersonation via MAPI still seems to work in Ex 2007 RU8.

• Anonymous
  April 27, 2011
  An additional difference is that in a cross forest situation Impersonation can fail, because it relies on certain Kerberos services. Delegation does not need these services.

• Anonymous
  February 06, 2015
  It would be nice to have an example for E2010 as it is not as easy as 2007. Here is an example to creating EWS impersonation for a group.  Any member of the group would be impersonated by the service account.  Two steps...create the New Management scope and then the Role assignment. New-ManagementScope “Scope Name” -RecipientRestrictionFilter {(MemberOfGroup -eq 'CN=group name,CN=Users,DC=Contoso,DC=com')} New-ManagementRoleAssignment -Name “EWS ROLE NAME” -Role applicationimpersonation -User DomainService Account -CustomRecipientWriteScope “Scope Name” Where “Scope Name” is the management scope created in step one.