curl-library
Re: problems using negotiate with sspi in 7.21.6
Date: Tue, 17 May 2011 04:02:38 -0700 (PDT)
Date: Mon, 16 May 2011 14:37:39 +0100
From: David Woodhouse <dwmw2@infradead.org>
To: Daniel Stenberg <daniel@haxx.se>
Cc: libcurl development <curl-library@cool.haxx.se>, Ibraheem
<ibraheempindi@yahoo.com>
Subject: Re: problems using negotiate with sspi in 7.21.6
Message-ID: <1305553061.8008.23.camel@i7.infradead.org>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2011-05-13 at 00:05 +0200, Daniel Stenberg wrote:
>> > 3) If Negotiate fails using kerberos, then it should fallback to ntlm, which
>> > is not working at all here
>>
>> libcurl actually doesn't fall back to another auth. It picks the one auth type
>> it thinks is best out of the ones the server offers and if that fails, the
>> request fails. Why would it fall back and do another try?
>In Windows environments it seems quite common for Kerberos support to be
>*claimed* but not actually functional. We need to fall back to NTLM in
>that case.
>IE and Firefox get this right, I believe, but Chrome does not:
>http://code.google.com/p/chromium/issues/detail?id=82646
But as far as i understood this fall back scenario. In negotiate protocol the API's(SSPI) for generating the context will choose of falling to NTLM token or Kerberos token automatically(of course it may depend on what client capabilities are, it has access to sspn or not...), and that token will go under the same Negotiate Header. As in our case the IIS server is using Negotiate protocol and we are setting to use any Auth method in libcurl. Now if the client computer is outside the domain, it will not be able to access sspn(server principle name) and hense can't generate kerberos token. So the token that SSPI will generate will be an NTLM token and it will be sent under the header of Negotiate, and the server will respond accordingly as in NTLM auth, but the libcurl Negotiate implementation treats the negotiate protocol as one cycle and if that fails it will fail, but in this case of it's an NTLM two cycle authentication, so that fails in libcurl.
So the problem mainly is not that of falling back to NTLM protocol if negotiate fails, but working of negotiate protocol in libcurl with ntlm type token is lacking. If i'm wrong here kindly explain.......
Thanks and anxiously waiting for the comments....
-regards
Ibraheem
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-05-17