Cross Forest Exchange Impersonation in Exchange 2007 Service Pack 1


In Exchange 2007, the Exchange Impersonation feature was introduced in Exchange Web Services to allow one account (the service account) to make web service calls on behalf of another account (the Act-As account).  Rather than the "delegate access" or "administrative" approach that most were used to, the call would actually be made using the rights of the Act-As account rather than the rights of the service account.

While setting up and using Exchange Impersonation in a single forest topology is rather straight forward, doing so in a multi-forest topology can be somewhat... challenging.  However, the EWS team is seeing the same issue come up over and over again which can thankfully be rectified by judicious use of PowerShell and a little explanation.

When Exchange is used in a multi-forest scenario, you will typically have the Exchange forest which contains a plethora of tastefully appointed mailboxes and then a user forest which contains the actual user accounts.  In such a scenario, the Exchange forest will contain "linked" mailboxes which are actual Active Directory user accounts that refer back to the associated user account in the user forest.  When a non-Exchange Impersonated EWS call is made by one of these user accounts, IIS forwards the authentication request over to the user domain which validates the identity of the caller and returns a user token to the CAS server in the Exchange forest.  This should work fine assuming that a trust relationship is set up between the forests.   Once the user is authenticated, EWS attempts to look up Exchange-specific information about the *caller* in the Active Directory, which of course refers to the Exchange forest.  In the normal case, there is indeed a user record (the linked mailbox) in the Exchange forest and EWS is able to proceed.

In cross-forest Exchange Impersonation, however, what will often happen is that a service account is created in the user forest.  The service account is going to perform work on behalf of mailbox users, but it doesn't need a mailbox of its own.  So the admin runs the two Add-AdPermission cmdlets in the Exchange forest to given the ms-Exch-EPI-Impersonation and ms-Exch-EPI-May-Impersonate rights to the service account.  Note that this is standard Windows Active Directory ACL manipulation here.  The domain controller in the Exchange forest creates a Foreign Security Principal object in the Exchange forest directory to represent the user in the user forest.

After the rights are configured properly, you try to test your application out by making an Exchange Impersonation call from the service account.  However, EWS responds with a SOAP fault containing a response code of "ErrorCallerIsInvalidADAccount" and the following error message:

Failed to get valid Active Directory information for the calling account.  Confirm that it is a valid Active Directory account.

As in the non-Exchange Impersonated call case, IIS forwards the authentication request over to the user domain which validates the identity of the caller (the service account) and returns a user token to the CAS server in the Exchange forest.  Once the user is authenticated, EWS attempts to look up Exchange-specific information about the *caller* in the Active Directory, which of course refers to the Exchange forest.  In this case, however, the only AD object representing the caller is the Foreign Security Principal put there by the domain controller when the ACLs were manipulated by Add-AdPermission.  As such, EWS cannot resolve the account and fails the request.

It should be apparent from the preceding discussion that what we need is an AD *user* object in the Exchange forest that represents the caller (the service account).  In reality, you could create just a normal AD User account or even an AD Contact object as long as the msExchMasterAccountSid attribute matches the objectSid of the corresponding account in the user forest.  In practice though, it is easier to create a "linked mailbox" for the service account in the Exchange forest using the Exchange Management Shell.

With this account set up, when an Exchange Impersonation request is received by EWS, it is able to resolve the service account to an Active Directory object in the Exchange forest and should service the request successfully.

- David Sterling


Share this post :

Comments (2)
  1. Jon says:

    It would be nice to see the example powershell commands in this blog

  2. Nicholas says:

    How as something as straightforward as e-mail turned into something as bloat-ridden and complicated as the articles on this site?

Comments are closed.

Skip to main content