RE: cross compiling NTLMv2 and gssapi configure issues
Date: Tue, 1 Apr 2014 20:31:15 +0100
On Tue, 1 Apr 2014, Ophir Orly wrote:
> The cause for the gssapi compilation issues is that the
> curl configure script uses krb5-config to get the compilation
> flags, and apparently we have that misconfigured.
That doesn't sound too good, and unfortunately goes over my head, but
perhaps one of *nix experts will be able to assist you with that.
> I thought it might be relevant since I've read something
> about NTLMSSP being removed from Windows Vista and
> Windows Server 2008 in favor of the Kerberos protocol.
My understanding is the NTLMSSP service has been removed in Windows Vista /
Server 2008 onwards. However, NTLM as an authentication mechanism still
works in products like Exchange and IIS - has to be enabled as an optional
extra in IIS.
Over the last few years I have had (lib)curl running on Windows 7, 8 and
8.1, Server 2008 R2, 2012 and 2012 R2 as well as previous editions
authenticating against Exchange 2010 and 2013 ;-)
> Will that cause issues with current NTLMv2 implementation?
It shouldn't do... Whilst I have a fairly good idea of SSPI and related
services/components I'm certainly not an expert so can't say 100% it won't.
> > I couldn't see it in your config options but were you building a debug
> > build by any chance?
> No. It's a normal build.
My only concern there was we have some debug code in there to assist with
the test cases and whilst it doesn't cause problems on Windows against
Exchange I did wonder if it was causing an issue for you.
> > > The Windows build - connects perfectly, but the linux one doesn't.
> > Did you compare the base64 authentication strings to see how much
> > they diff by?
> Not yet. I'll do that
It will be interesting to see if there are any differences - I would expect
a couple of bytes here and there (to do with timestamps and random numbers)
but not too much. I wouldn't recommend posting authentication strings here
but if you want to ping me a private email I don't mind taking a look if you
need me to.
You can also try base64 decoding them but you'll end up with binary data
which you will need to look at in a hex editor.
If you try taking a look at it yourself you might find the following
In verbose mode you should see curl send a message to the server which has a
base64 authentication string - that will be the type 1 message.
The server will then respond with a type 2 response.
Curl will then send a type 3 message to the server. It *should* be that one
that causes the failure. Saying that it could be type 1 if it has failed to
decode it, it is missing, or data in the string is corrupt :(
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2014-04-01