Exchange Web Services and SharePoint without ApplicationImpersonation No ratings yet.

A question that I have seen crop up quite a bit on the internet is how to use EWS with a SharePoint webpart.  Using EWS is quite easy, as you can simply reference the managed API and use that – but the main implementation headache is how to set up authentication.  A lot of customers do not want to use a service account (i.e. a domain account that has ApplicationImpersonation rights to all mailboxes) due to security concerns.  The good news is that in a domain environment we can use Kerberos and delegation to pass the user’s credentials to EWS.  I have created a sample web-part that shows some messages from the user’s inbox, and configured my test system to work this way.  The process wasn’t entirely straight-forward, so I am documenting it here.  Note that my set-up is a lab environment and I have taken a few shortcuts (e.g. using the same service account for all SharePoint services) that you probably wouldn’t want to do in a production environment.


My Exchange environment is 2010 SP2, split into three sites (currently one Exchange server in each site, with all roles installed on each server).  There is also a DC in each site.

I installed SharePoint 2010 on an additional server in one site.

SharePoint Web-part

The web-part simply queries some items from the user’s Inbox (either Unread mail, or the first x items).  It uses the EWS Managed API, and is set to use default credentials (i.e. the credentials of the user visiting the SharePoint site).  I’ve attached the full source of the web-part to this blog.

Configuring Kerberos and Delegation

This was the part that took me a fair while.  Note that EWS supports Kerberos by default, so the main configuration is Sharepoint, and setting up the delegation rights.

Set up Kerberos

  • To configure SharePoint to use Kerberos, I followed this guide: .  I created a domain account (I chose a user account) called sharepoint_svc, so in the following steps I refer to this account.  I also used this account for all services, instead of setting up separate accounts – this made implementation in my lab environment easier, but it is recommended to use different service accounts in a production environment.
  • To test that Kerberos was working correctly for EWS, I used KerbTray to check the Kerberos tickets, and SOAPe to test autodiscover and send a basic EWS request.  When testing, no credentials should be entered so that default credentials (i.e. those of the logged in user) are used.
  • To test that Kerberos was working with SharePoint, I used KerbTray.  If you are not prompted for credentials when you browse to the SharePoint site, and you see a Kerberos ticket for the site once it is open, then Kerberos is working properly.

Set up Delegation

  • Once Kerberos is working, delegation needs to be set up.  This is because the SharePoint web-part impersonates the end-user and it is the SharePoint server (not the client) that is querying EWS – therefore, the SharePoint server needs to have delegation rights.
  • From Active Directory, grant the SharePoint service account (sharepoint_svc) delegation rights (from the Delegation tab in the ADUC object properties).  In my lab I set the option “Trust this user for delegation to any service (Kerberos only)”.  In a production environment, you may want to limit the rights to specified services (EWS).
  • Follow the steps in KB 2722087.

Once the above steps were complete, the web-part then worked as expected.  The only other thing to note is that Internet Explorer must be configured to use Windows Authentication, and the SharePoint site must be within a security zone where this can apply (in my case the site was within local intranet).  Looking at the steps above, it looks deceptively simple.  I guess it actually is, but only when you have the steps listed – it took me a fair while to work out what was going on at certain points!

Please rate this


Leave a Reply

Your email address will not be published. Required fields are marked *