Hi Steve,

> Was the log you included this time from the SSPI build or the non-SSPI
> build as the type-3 message seemed to be sent in it?

The latest log was produced by the non-SSPI build.

> Whilst I am one of libcurl's regular contributors, my specialities are
> the email protocols and SASL authentication mechanisms. Whilst the
> NTLM code forms part of this knowledge I am not too familiar with the
> HTTP code that uses it and may require assistance and input from my
> fellow hackers:

Maybe I will be able to provide more detailed information on Wednesday. I
scheduled testing of the authentication process, that includes a guy watching
on the proxy server side, logging the network traffic during the tests.

> I believe the reason we see no error code from libcurl, in this
> instance, is that http.c:Curl_http_input_auth() always returns
> CURLE_OK when calling the individual authentication functions. If
> anything goes wrong in those functions it seems to just output the log
> message you saw and set data->state.authproblem to TRUE. I would
> recommend we review this after the pending release and change the
> design so that error codes from nested functions are pushed up the
> call stack.

I certainly will continue to analyze this issue. It is extremely important to solve
the authentication problems. Currently up to 70 users (working for the same
company from different international locations using different proxy servers)
are affected by this problem. However, I'm still not absolutely sure whether
this is really a libcurl problem or whether some configuration issues on the
proxy side at least contribute to the problem.

> This doesn't explain the problem you are seeing but I thought it was
> worth mentioning - if the code was changed to push the error code up
> the stack then we should have received a CURLE_REMOTE_ACCESS_DENIED.
>
> > Text: Connected to 11.22.33.44 (11.22.33.44) port 9090 (#0)
> > Text: Proxy auth using NTLM with user 'ABCDE'
>
> I appreciate you have masked the username to protect identities, but
> was the domain specified in the username?

No. Just the user id.

> If not, are things any different if it is included?

This was not yet tested. At least it shouldn't be necessary, because the users
access the Internet through the same proxy from their browsers (Firefox and
Internet Explorer) without problems. For this they use the same proxy server,
the same user id (without domain) and password.

> I would agree, the server seemed to ignore/reject the type-3 and sent
> back a 407 response. As such libcurl then printed out the extra log
> information you mentioned as curl_ntlm.c:Curl_input_ntlm() was called
> in an invalid state, ie (ntlm->state == NTLMSTATE_TYPE3) was TRUE.
>
> I can't explain why the server is rejecting the type-3 message - I can
> only assume it is something to do with the user account/machine that
> is having problems.

I'm quite convinced that this is a more general problem, since different users
from different countries using different proxy servers are affected.

> I have assumed this log was the non-SSPI build as the log differed
> from your previous email - in those logs it looked like either the
> type-2 message wasn't being processed successfully by the libcurl/SSPI
> code or the type-3 message wasn't being generated correctly.

Yes, indeed. At least the request with the type-3 message was not issued, so
most likely the failure occurred already on processing the type-2 message.

> If that is the case I would have expected libcurl to give you a
> CURLE_RECV_ERROR rather than a CURLE_OK if my understanding
> of the HTTP code is correct.

This log was produced by a version of the application that didn't check the
libcurl error code. That is, in principle there could have been a real error. I
will try to repeat this test on Wednesday.

> If you fancy hacking libcurl a bit, to see whether the SSPI build can
> help identify the cause, then you could try adding some logging to
> curl_ntlm_msgs.c:Curl_ntlm_create_type3_message() to see what the
> value of "status" is when s_pSecFn->InitializeSecurityContext() is
> called - line 663 (in the current repo).

I'll take a look tomorrow and will prepare several versions for the tests on
Wednesday (SSPI, non-SSPI, additional messages ...). I really have to get
this working somehow ...

I appreciate your support very much.

Regards,

Ulrich

-- 
E-Mail privat:  Ulrich.Telle_at_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