A customer had a query regarding the Exchange integration:

What is the purpose of using an impersonated user? Would it not be better from a security perspective to have the CRM Exchange integration log in as each individual user when accessing mailboxes, rather than have a single user with the ApplicationImpersonation role access all mailboxes?


There's a number of reasons why we use an impersonated user. The most immediate, and most practical one is password management. If you store individual user's passwords, then you will have to update those passwords in CRM every time that the users change their passwords. This is impractical, especially for integrations with large numbers of users, or where the users' passwords are set to expire on a regular basis.

This differs from the classic Outlook integration, where the synch is run from each individual user's machine. Using this model, each user authenticates individually on Exchange when they log into Outlook. Having a centralised synch allows the integration to work when users aren't logged on to Outlook, and also allows for much improved performance when synching a large number of users.

Because the impersonated user can update other user's mailboxes, we don't recommend using a normal user account for the impersonation. We would suggest setting up a machine (or service) account which would not be associated with anyone's personal mailbox. This approach is also used for other applications that use impersonation, such as IIS (using the IUSR or a domain anonymous user), or an impersonated user account for file access (e.g. the impersonated user account for the CRM library).  In those latter examples, the impersonated user account has fewer rights than a normal user account, thereby providing additional security.

More info:

One question we are sometimes asked is whether it's possible to set the impersonated user up so that they don't have rights on all Exchange mailboxes, instead only giving it rights on the mailboxes of integration users. This can be done; instructions are available in KBA 492-16188.