I am writing a program to dump the contents of numerous mailboxes from an Exchange server using EWS in C#. Using fiddler I noticed that each request I send makes a new connection (tunnel), with a new authentication process being undertaken (using negotiate). My ServerCertificateValidationCallback gets called for every request.

If I enable the option in Fiddler to "reuse server connections" than the connection is only created during handshaking, and is re-used for all requests (saving lots of time).

By getting the EWS source and modifying the requests I found if I enable "UnsafeAuthenticatedConnectionSharing" on the request objects than the connection is re-used (extra tunnels & ServerCertificateValidationCallbacks disappear), but each request still requires the full handshake authentication. This is because the server sends back a 401 when ever I try and use the exchange cookie.

Is there any way I can re-use my server connection & authentication?

public class EwsExchange
{
    static int Main(string[] args)
    {
        sslCertCheckCount = 0;
        ServicePointManager.ServerCertificateValidationCallback = ServerCertificateValidation;

        ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010_SP1);
        service.Credentials = new NetworkCredential(args[1], args[2]);
        service.Url = new Uri(args[0] + @"/EWS/exchange.asmx");
        service.KeepAlive = true;
        service.PreAuthenticate = true;
        //service.UnsafeAuthenticatedConnectionSharing = true;

        Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox, new PropertySet(FolderSchema.Id, FolderSchema.DisplayName));
        FindItemsResults<Item> res = folder.FindItems(new ItemView(int.MaxValue));

        return 0;
    }

    public static bool ServerCertificateValidation(Object obj, X509Certificate certificate, X509Chain chain, System.Net.Security.SslPolicyErrors errors)
    {
        Console.WriteLine(String.Format(" ****************** ServerCertificateValidation - count: {0}. ****************** ", ++sslCertCheckCount));
        return true;
    }

    static int sslCertCheckCount;
}

Thanks!

As you probably know the Managed API is using HttpWebRequest under the covers so the 401 behaviour is a (feature) of this class. You might want to look at http://weblog.west-wind.com/posts/2010/Feb/18/NET-WebRequestPreAuthenticate-not-quite-what-it-sounds-like I've done this in the past with sites that use basic auth by manually setting the basic auth header which is easy(I've seen a few other people post alternative workarounds on Stackoverflow if you search on HttpWebRequest ).

Cheers
Glen

As you probably know the Managed API is using HttpWebRequest under the covers so the 401 behaviour is a (feature) of this class. You might want to look at http://weblog.west-wind.com/posts/2010/Feb/18/NET-WebRequestPreAuthenticate-not-quite-what-it-sounds-like I've done this in the past with sites that use basic auth by manually setting the basic auth header which is easy(I've seen a few other people post alternative workarounds on Stackoverflow if you search on HttpWebRequest ).

Cheers
Glen

• Proposed as answer by Jason Johnston [MSFT]Microsoft employee, Moderator 4 hours 10 minutes ago

As you probably know the Managed API is using HttpWebRequest under the covers so the 401 behaviour is a (feature) of this class. You might want to look at http://weblog.west-wind.com/posts/2010/Feb/18/NET-WebRequestPreAuthenticate-not-quite-what-it-sounds-like I've done this in the past with sites that use basic auth by manually setting the basic auth header which is easy(I've seen a few other people post alternative workarounds on Stackoverflow if you search on HttpWebRequest ).

Cheers
Glen

• Proposed as answer by Jason Johnston [MSFT]Microsoft employee, Moderator Wednesday, May 13, 2015 3:17 AM
• Unproposed as answer by CHaddad86 Wednesday, May 13, 2015 10:31 PM

I already tried this.  I added the auth header for negotiate with the key, but it ignored it and sent me back a 401 any way.   I then turned basic auth on as a test and added a basic auth header and that worked great.  But unfortunately I need it to work with the more secure negotiate.

So it turns out that after I modified the EWS API to allow me to enable UnsafeAuthenticatedConnectionSharing on the HttpRequests, that my connection and authentication were actually being re-used.

Fiddler was the one dropping my connections after I disabled the option "Tools -> Fiddler Options -> Connections ->  Reuse server connections".  Running wireshark on the exchange server machine showed that when fiddler was capturing with this option disabled the FIN TCP flag was being set, ending the session.   But without fiddler capturing the connection & session were both re-used.

• Marked as answer by CHaddad86 6 hours 56 minutes ago

So it turns out that after I modified the EWS API to allow me to enable UnsafeAuthenticatedConnectionSharing on the HttpRequests, that my connection and authentication were actually being re-used.

Fiddler was the one dropping my connections after I disabled the option "Tools -> Fiddler Options -> Connections ->  Reuse server connections".  Running wireshark on the exchange server machine showed that when fiddler was capturing with this option disabled the FIN TCP flag was being set, ending the session.   But without fiddler capturing the connection & session were both re-used.

• Marked as answer by CHaddad86 Friday, May 15, 2015 12:32 AM