curl-library
Re: Problem with NTLM proxy authentication
From: Ulrich Telle <Ulrich.Telle_at_gmx.de>
Date: Tue, 09 Sep 2014 23:31:19 +0200
Date: Tue, 09 Sep 2014 23:31:19 +0200
Steve,
thanks for taking the time to further investigate this problem.
> 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?
No. However, they are both hosted by the same provider.
> 1a) If not, what software was each proxy server running and are they
> on different domains?
They are on different domains. However, as far as I know on both proxy
servers the same software, McAfee Web Gateway, is running.
> 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?
All different.
> 2a) If they were different machines. are the machines on different
> domains or running different versions of the OS?
Different domains; same OS version.
> > 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 :(
It is really strange that Windows SSPI doesn't work for my application and
the users in that one company. It is even stranger, because the user I'm in
contact with to perform the tests has no problem to access the Internet using
his FireFox browser. And as far as I know FireFox uses Windows SSPI, too.
I intend to analyze the NTLM handshake of FireFox with the proxy server. I
will have an opportunity to do so on Thursday. Maybe this can give additional
hints.
At least I already found out within my own company, that the NTLM
handshake messages look a bit different if done from FireFox than if done
from my own application.
Here are the flags in the Type-1 message:
FireFox: A2 08 82 07
#define NTLMSSP_NEGOTIATE_UNICODE 0x00000001
#define NTLMSSP_NEGOTIATE_OEM 0x00000002
#define NTLMSSP_REQUEST_TARGET 0x00000004
#define NTLMSSP_NEGOTIATE_NTLM 0x00000200
#define NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0x00008000
#define NTLMSSP_NEGOTIATE_NTLM2 0x00080000
#define NTLMSSP_NEGOTIATE_128 0x20000000
#define NTLMSSP_NEGOTIATE_56 0x80000000
My application: E2 08 B2 B7
#define NTLMSSP_NEGOTIATE_UNICODE 0x00000001
#define NTLMSSP_NEGOTIATE_OEM 0x00000002
#define NTLMSSP_REQUEST_TARGET 0x00000004
#define NTLMSSP_NEGOTIATE_SIGN 0x00000010
#define NTLMSSP_NEGOTIATE_SEAL 0x00000020
#define NTLMSSP_NEGOTIATE_LM_KEY 0x00000080
#define NTLMSSP_NEGOTIATE_NTLM 0x00000200
#define NTLMSSP_NEGOTIATE_DOMAIN_SUPPLIED 0x00001000
#define NTLMSSP_NEGOTIATE_WORKSTATION_SUPPLIED 0x00002000
#define NTLMSSP_NEGOTIATE_ALWAYS_SIGN 0x00008000
#define NTLMSSP_NEGOTIATE_NTLM2 0x00080000
#define NTLMSSP_NEGOTIATE_128 0x20000000
#define NTLMSSP_NEGOTIATE_KEY_EXCHANGE 0x40000000
#define NTLMSSP_NEGOTIATE_56 0x80000000
No idea, what triggers this different set of flags.
One difference I see in the source code of the SSPI authentication module of
FireFox is that SSPI function InitializeSecurityContext is called without any of
the flags libcurl is using:
ISC_REQ_CONFIDENTIALITY |
ISC_REQ_REPLAY_DETECT |
ISC_REQ_CONNECTION
And maybe FireFox sends additonal HTTP headers, which my application
does not send, but that are taken into account by the proxy server. (Of
course this is just wild guessing.)
> > 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.
Me too. And within my own company it does. So there doesn't seem to be an
obvious problem in the code of libcurl.
> 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.
Maybe we just miss a subtle detail.
> 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)?
That is, you'd like to see the results if libcurl forces to not use NTLMv2.
Not impossible, but it will take some time.
Is there a way to force SSPI to not use 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.
Could be. I hope this will get clearer after I checked the NTLM handshake as
done by FireFox in the user's company.
Regards,
Ulrich
--
E-Mail privat: Ulrich.Telle@gmx.de
World Wide Web: http://www.telle-online.de
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-09-09