HttpWebRequest over Https Via Proxy Fails using NTLM

  • Thread starter Thread starter Lenster
  • Start date Start date
L

Lenster

A C# (.NET 2) application which uses the System.Net.HttpWebRequest object to
request a resource over HTTPS is failing following the installation of a new
proxy server on our internal network with 407 Proxy Authentication Required.

The same request through the old proxy succeeds.

The same request to an HTTP address through the new proxy succeeds.

Also, the request succeeds when forced to use Basic authentication but fails
on NTLM.

Tracing network packets when forcing the request to use NTLM reveals the
credentials passed up to the proxy are being corrupted so that they only show
the first character of the username, domain and hostname.

The network trace shows that the old proxy responds with HTTP1.1 and the new
one responds with HTTP1.0 - I'm not sure if this is significant.

The code used to perform the request can be seen below.



private void LoadResource(string URL)
{

HttpWebRequest wreq;
HttpWebResponse wresp;
CredentialCache credCache;

wresp = null;

try
{
// Force NTLM Authentication by removing all other authentication
modules...
AuthenticationManager.Unregister("Basic");
AuthenticationManager.Unregister("Kerberos");
//AuthenticationManager.Unregister("Ntlm");
AuthenticationManager.Unregister("Negotiate");
AuthenticationManager.Unregister("Digest");

wreq = (HttpWebRequest)WebRequest.Create(URL);
wreq.Proxy = System.Net.WebProxy.GetDefaultProxy();
wreq.Proxy.Credentials = new CredentialCache();

NetworkCredential cred = new NetworkCredential(txtUserName.Text,
txtPassword.Text, @"mydomain");

((CredentialCache)wreq.Proxy.Credentials).Add(new
Uri(((WebProxy)wreq.Proxy).Address.AbsoluteUri), "Negotiate", cred);

((CredentialCache)wreq.Proxy.Credentials).Add(new
Uri(((WebProxy)wreq.Proxy).Address.AbsoluteUri), "Ntlm", cred);

((CredentialCache)wreq.Proxy.Credentials).Add(new
Uri(((WebProxy)wreq.Proxy).Address.AbsoluteUri), "Basic", cred);

((CredentialCache)wreq.Proxy.Credentials).Add(new Uri(URL),
"Basic", cred);

((CredentialCache)wreq.Proxy.Credentials).Add(new Uri(URL), "Ntlm",
cred);

((CredentialCache)wreq.Proxy.Credentials).Add(new Uri(URL),
"Negotiate", cred);

wresp = (HttpWebResponse)wreq.GetResponse();
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
finally
{
if (wresp != null){wresp.Close();}
}

}



As the request succeeds on the old proxy I suspect that the challenge
response sent back from new proxy must be causing something different to
happen within the .net ntlm authentication module resulting in the corrupted
credentials being sent back to the proxy.

Is there any way to debug the ntlm authentication module to see exactly what
is going on during the request or can anyone give me an example of a custom
ntlm authentication module to try - I only seem able to find custom basic
authentication examples ?

Any help greatly appreciated...
 
you should check the proxy authenication request headers to see which
authenication schemes it allows. it may only support basic. NT/LM requires
http 1.1 because it requires keep-alives.


-- bruce (sqlwork.com)
 
The proxy authentication header returns Basic, NTLM, and Negotiate.

I can force my application to only use basic and the request is successful but
when I force the application to use NTLM the problem occurrs.

Additionally, the problem only occurs when requesting an https address.
http addresses authenticate using NTLM no problem but obviously the
authentication handshake is diferent with http sending a GET whereas https
sends CONNECT etc.

A network trace shows that the https request handshake is as follows :

Client : Send CONNECT
Proxy : Send 407 Authentication Required (Basic, NTLM, Negotiate)
Client : Send CONNECT with NTLMS_NEGOTIATE
Proxy : Send 407 Authentication Required (NTLMSSP_CHALLENGE)
Client : Send CONNECT with NTLMSSP_AUTH (At this point the credentials
appear corrupted - only first character of username, domain and hostname are
displayed in the trace)
Proxy : Send 407 Authentication Required (Due to invalid credentials)

I understand what you are saying about HTTP1.1 and keep alives but wouldn't
that also prevent the http requests failing over NTLM if that was a problem ?
 
I know this doesn't help, but did you find a fix for this problem? I am having exactly the same intermittant problem with only the first characters of the domain/userid being passed to the NTLM challenge.

Thanks
 
the only fix is to change the proxy server to one that will supports NTLM.
your other option is to switch to basic authenication over ssl.

-- bruce (sqlwork.com)
 
Back
Top