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 information useful: 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 :( Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
