Exchange Web Services and SharePoint 2013 without ApplicationImpersonation


I previously wrote an article showing how to set up Sharepoint 2010 to be able to access users’ mailboxes using EWS and integrated authentication (i.e. no service account was needed for the EWS calls).  Things have changed with Sharepoint 2013, so this article details the process with the latest versions of the products (at the time of writing, this is Exchange 2013 and Sharepoint 2013).

Environment

For my lab, I have a single domain (e15.local) with a single Exchange 2013 organisation consisting of one CAS and one MBX.  I have a dedicated SQL server (sql.e15.local), and a dedicated Sharepoint server (sharepoint.e15.local) that is installed in production mode.  The installation of Sharepoint was fairly straight-forward, and involved these steps:

  1. Install SQL Server (I used SQL Server 2014) – in my lab, this was to a dedicated server named sql.e15.local.
  2. Install Sharepoint, and when prompted choose the Production environment option (even though it is in my lab, this option is required to enable Sharepoint farm, etc.)
    1. Create service account (in Active Directory) for database access (and grant necessary permissions on SQL server instance).  My service account is e15\sharepointsql.
    2. Run the Sharepoint configuration wizard.
    3. Create new server farm, using sql.e15.local as the database server.  When asked, authentication mode is set to Negotiate (Kerberos).
    4. Set the SPNs for the sharepoint server/service account:
      setspn -S HTTP/sharepoint e15\sharepointsql
      setspn -S HTTP/sharepoint.e15.local e15\sharepointsql
      In Active Directory, open the computer object for the Sharepoint server, and enable delegation (Trust this computer for delegation).
  3. You will now be able to access Sharepoint Administration to continue the configuration.
  4. Create and configure the new Sharepoint website
    1. Go to Application Management… Manage Web Applications, create new web application
    2. Create new site collection (also from Manage Web Applications).
    3. From Application Management, select the new Sharepoint site, and then click Authentication Providers.
    4. Change the authentication to Negotiate (Kerberos)
    5. Integrated Windows Authentication should now be working, meaning that if you browse to the site you will automatically be logged in.
  5. The basic Sharepoint set-up is now complete (for my purposes, anyway!).  At this point all I did was add a few test accounts so that I could test client functionality once the web-part was added.

Sharepoint Web Part

The sample web part is attached to this post, and is an updated version of the previous web part (which displays a few messages from the user’s Inbox).  In this case, I recreated the project in Visual Studio 2013 and updated to the latest EWS Managed API (2.2 at time of writing). The basic code is the same as the web-part I created for Sharepoint 2010, though I have added more debugging to it (including EWS tracing).  The most important change, though, is the code used to obtain a WindowsIdentity and then impersonate it, which needs to be done before the calls to EWS.  This code is:

// Get a windows identity that we can use for impersonation
 IClaimsIdentity identity = (ClaimsIdentity)Thread.CurrentPrincipal.Identity;
 string upn = identity.Claims.Where(c => c.ClaimType == ClaimTypes.Upn).First().Value;

if (String.IsNullOrEmpty(upn))
 {
 throw new Exception("No UPN claim found");
 }

WindowsIdentity windowsIdentity = null;
 SPSecurity.RunWithElevatedPrivileges(delegate()
 {
 windowsIdentity = S4UClient.UpnLogon(upn);
 });

using (WindowsImpersonationContext ctxt = windowsIdentity.Impersonate())
 {
 // EWS code, using default credentials, goes here - and will authenticate as the Sharepoint user
 }

Configuring Kerberos and Delegation for EWS

The first step is to set up the Claim to Windows Token Service.  The procedure for this is the same as it was for Sharepoint 2010, and is described in KB 2722087.  I set the service to use the same service account that the Sharepoint application pool is running in (in my case, e15\sharepointsql).  One important point to note is that the delegation needs to be set up to use any authentication protocol, and a service needs to be added (though what the service is, is irrelevant, as explained in the KB).  If delegation is set up for any service, or Kerberos only, then the C2WTS service will not be able to obtain the Kerberos token (and you’ll get access denied for EWS):

Delegation settings for C2WTS account

In the screenshot above, note that CAS1 is the computer name of the CAS to which the EWS requests are sent.  Also note that this is hardcoded in the webpart, so you will need to update the EWS URL according to your environment and then recompile.

That should be it, as the SPNs have already been set up during Sharepoint configuration.

InboxViewer2013.zip

Comments (1)

  1. thanks a lot for your work, I tried over my lab and it is working fine.

Skip to main content