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.
Exchange Server 2007, SP1, Impersonation, Knowlegebase