Share via

The Double-Hop Dogma

  • Article

If you find yourself wondering why your robustly developed, uber-comprehensive ASP.NET application, which is supposed to dive into the Exchange mailbox of the authenticated user and leverage the very convenient and efficient Exchange Web Services (Managed API or otherwise) to pull out their e-mails, contacts, meetings and so on and so forth, isn’t able to access their mailbox items… or if you’re encountering other Exchange-related unexplainable symptoms, such as failure of Autodiscover to pull the URL of the CAS server, the truant at play might just be authentication.

To make sure that the Autodiscovery service is accessible from the WebServer, you could download the EWSEditor Tool (Link) and use that to test Autodiscover:

 

Fact is that unless your credentials are passed successfully to the Exchange Server through the ExchangeService object, Autodiscover is likely to throw tantrums, even one as misleading as '”The Autodiscover service couldn’t be located”. A quick way to make sure that the issue isn’t indeed because of inavailability of Autodiscovery, is by hardcoding credentials of a mailbox in the ASP.NET application (for diagnostic purposes), and see whether autodiscover works in that scenario and mailbox items are fetched for the mailbox whose credentials are hardcoded, when you browse the ASP.NET application from a client machine.

 

//Original Code        

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP1);

service.UseDefaultCredentials = true;

         service.AutodiscoverUrl("<sampleMailbox@domain.com>");

 

//Diagnostic Code

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP1);

         service.Credentials = new WebCredentials("<sampleMailbox>", "<password>", "<domain>");

         service.AutodiscoverUrl("<sampleMailbox@domain.com>");

           

So the obvious question is… what are we doing wrong? The IIS application should be running under the identity of the logged on user and ought to be passing his/her credentials onwards to Exchange to fetch his mailbox items via EWS, right?

Ideally, yes. (And in this context, the ideal isn’t impossible to achieve).

What we’re observing here is a double-hop scenario. The user who’s browsing the application from a client machine passes his credentials to the IIS server, i.e. the credentials of the user hop from the client to the IIS server. Subsequent to that, when the IIS application executes EWS calls, it is supposed to pass those same credentials to the Exchange server, to authenticate the logged on user. This works fine in the ideal scenario, and falters in alternative scenarios.

Ideal scenario: Kerberos authentication method is being used within the organization 
Frequent Scenarios: The non-ideal scenario is not being observed, i.e. NTLM might be the active authentication mechanism, or Kerberos could be failing and the application falls back on attempting authentication via NTLM which would eventually fail in a double-hop situation.

 

Here are the action items that you'd have to implement to allow end-to-end authentication in this context (i.e. they ought to be comprehensive for most scenarios):  

1. Enable your ASP.NET application to use Kerberos ("Negotiate") authentication, along with NTLM: https://support.microsoft.com/kb/215383

2. Additionally, ensure that the ASP.NET application is allowed to impersonate: https://support.microsoft.com/kb/306158

3. Enable Kerberos authentication on your Exchange Client Access Servers: https://technet.microsoft.com/en-us/library/ff808312.aspx
    For this specific step, relevant SPN's need to be set for the services involved. However, presence of duplicate SPN's can disrupt access to the service, and this step should be executed carefully, involving Microsoft Support if required. (https://blogs.technet.com/b/askds/archive/2008/06/09/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.aspx)

4. Enable the Service Account configured for the AppPool your ASP.NET application is running under, for Delegation: https://technet.microsoft.com/en-us/library/cc784032(v=ws.10) (Similar steps need to be followed for Windows Server 2008 and 2008 R2).
Factor to consider... General Delegation vs. Constrained Delegation: https://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

 

The entire process is rather complex, and would require collaboration from your application developers, Exchange Admins and Admins who manage Active Directory and the Application Server.
If you feel the need to reach out to Microsoft Support to address this issue, be sure to quote this article so that we can assist you in an efficient manner.

  

Cheerio!