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.
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: http://www.microsoft.com/en-us/download/confirmation.aspx?id=23176 . 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!