Share via

Exchange API Team Blog: Exchange Impersonation vs. Delegate Access…

  • Article

The Exchange API team has a new post to explaining the differences between using Exchange Impersonation vs. Delegate Access to access an Exchange mailbox using Exchange Web Services.  I’ve seen first hand that there is a gap in understanding the difference between the two and when to use one versus the other.  This post goes a long way to address some of the confusion.

An important note that some people miss is the differentiation between Windows and Exchange impersonation – they’re not the same thing and more importantly, they aren’t even related…

“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.”

Conversely, the posts describes delegate access as…

“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…

…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.”

…To be clear, delegate access can be granted by an administrator on an entire mailbox (but not to specific folders within the mailbox) using the Add-MailboxPermission cmdlet but as the above statement points out individuals can also grant delegate access for other users to access specific folders in their mailbox or the entire mailbox.

A major difference between impersonation and delegation is that as far as Exchange Web Services and Outlook Web Access are concerned there is no way to assign a single delegate access to multiple mailboxes expect by establishing the delegate relationship for each individual mailbox.  I’ve talked about this before, the Exchange team describes it this way…

“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…

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

…This is a great post and a worthwhile read but from working with many customers to help them understand these concepts, I’d like to add some additional information and emphasize some key points…

Understanding the Requests

To emphasize a side point in the blog post there are three methods of mailbox to access a mailbox: Exchange Impersonation, Delegate Access, and Direct Logon.  The article doesn’t provide examples of what the XML looks like in each type of access request using Exchange Web Services.  For understanding, I’ve provided them below…

Direct Logon

<GetFolder>
  <FolderShape>
    <t:BaseShape>AllProperties</t:BaseShape>
  </FolderShape>
  <FolderIds>
    <t:DistinguishedFolderId Id="inbox"/>
  </FolderIds>
</GetFolder>

Delegate Access

<GetFolder>
  <FolderShape>
    <t:BaseShape>AllProperties</t:BaseShape>
  </FolderShape>
  <FolderIds>
    <t:DistinguishedFolderId Id="inbox">
      <t:Mailbox>
<t:EmailAddress>
          someoneelse@contoso.com
        </t:EmailAddress>
</t:Mailbox>
    </t:DistinguishedFolderId>
  </FolderIds>
</GetFolder>

Exchange Impersonation

<soap:Header>
  <t:ExchangeImpersonation>
<t:ConnectingSID>
<t:PrimarySmtpAddress>
someone@contoso.com
</t:PrimarySmtpAddress>
</t:ConnectingSID>
</t:ExchangeImpersonation>
</soap:Header>
<soap:Body>
  <GetFolder>
    <FolderShape>
      <t:BaseShape>AllProperties</t:BaseShape>
    </FolderShape>
    <FolderIds>
      <t:DistinguishedFolderId Id="inbox"/>
    </FolderIds>
  </GetFolder>
</soap:Body>

…The example above is for explicit delegate access.  You can also access a mailbox using implicit delegate access by specifying a FolderId which links to another mailbox.  All Ids returned by EWS embed their mailbox information in them so requesting them without explicitly specifying a mailbox will also work.

Putting It All Together

The terms used here come from the way Exchange Impersonation (also called Server-to-Server or S2S Authentication) is explained in the Inside Exchange Web Services book.  The book describes three types of accounts that come into play when accessing a mailbox: the Service account, the Act As account, and the Mailbox account.  Understanding how these accounts are affected by different mailbox access types is important.  The Service account is the account used to generate the XML requests and authenticate to the virtual directory, the Act As account is the account which will be used to authorize actions taken against a mailbox, and the Mailbox account is the actual resource you are trying to access.  In the grid below suppose you have an EWS application which runs as a user called ApplicationAccount, here is how the different access types affect each account context…

Access Type Service Account Act As Account Mailbox Account
Exchange Impersonation ApplicationAccount the impersonated account as specified in the ExchangeImpersonation property of the request any mailbox that the Act As account has mailbox rights to through Add-MailboxPermission or through permissions granted through Outlook, OWA, or EWS directly on a mailbox folder.
Delegate Access ApplicationAccount always ApplicationAccount any account or mailbox folder that ApplicationAccount has mailbox rights to through Add-MailboxPermission or through permissions granted through Outlook, OWA, or EWS directly on a mailbox folder.
Direct Logon ApplicationAccount always ApplicationAccount always ApplicationAccount

Comments

  • Anonymous
    July 22, 2009
    Note that with Add-MailboxPermission, not all 'features' of Delegate Access are enabled, even with the FullAccess option. For example: If an Administrator were to set Matt to have FullAccess to Ben's mailbox, that still doesn't mean that meeting requests sent to Ben will automatically be delivered to Matt in his mailbox.  This feature of having meeting requests forwarded to delegates can only be enabled through the use of Outlook's Delegate pane or the EWS Delegate Management methods (http://msdn.microsoft.com/en-us/library/bb856532.aspx)

  • Anonymous
    July 22, 2009
    Great point, this brings up a topic that I wanted to address in an upcoming post.  In conversations I've had recently there seems to be some confusion between delegate features and delegate access.