cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: Problem with NTLM proxy authentication

From: Steve Holme <steve_holme_at_hotmail.com>
Date: Tue, 9 Sep 2014 20:29:00 +0100

On Fri, 05 Sep 2014, Ulrich Telle wrote:

> I manually checked the NTLM Type-2 message received from the
> proxy server - one case where the call to InitializeSecurityContext
> failed,and one where it was successful.

Where these on the same proxy server?

1a) If not, what software was each proxy server running and are they on different domains?
1b) If so, what was the difference in the users credentials (domain, permission groups, etc...) and were the users from the same machine or from different machines?

2a) If they were different machines. are the machines on different domains or running different versions of the OS?

> In fact, I didn't see a signficant difference in the Type-2 messages. Both
> started with the zero-terminated string NTLMSSP, followed by the
> type-2 indicator. Then followed by 8 zero-bytes. Then the same flags in
> both cases:
>
> 35 82 89 E0 ==> long int: E0898235
>
> Then an 8-byte challenge (different, of course), followed by 16
> zero-bytes.
>
> The description of the function InitializeSecurityContext lists for return
> code
>
> SEC_E_INVALID_TOKEN
>
> I don't believe that the challenge token was corrupted in transit. So maybe not
> the proper security package was negotiated.

Me neither... from my experience Windows SSPI tends to give that when it doesn't like something in the message that you give it - it's unfortunately a little bit too generic in that sense :(

> I'm not an expert for NTLM or Windows security. So I'm still at a loss, what
> causes the observed authentication problems.

Me too and apologies for all the questions but I expect Windows SSPI just to work.

If there were ONLY problems with the "native" libcurl NTLM code base and not the SSPI code then I would say we have something wrong with our message encoding level, flags or something else but it seems weird that the SSPI code should fail this way.

Is there any chance you can try a non-SSPI build of libcurl prior to v7.36 (Which is when we added native support for NTLMv2)?

I think Daniel mentioned it in his email but I am wondering if, after searching around the web, if the proxy server has issues with NTLMv2 authentication.

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-09-09