On Mon, 01 Sep 2014, Ulrich Telle wrote:

> > Just out of interest have you tried a non-SSPI build?
>
> In the meantime I generated a non-SSPI version of my application
> and one user tested it, again without success.

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?

> > What return code do you get back from libcurl?
>
> The return code is always CURLE_OK, that is, no error. However, the
> HTTP response code keeps to be 407.

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:

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.

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.

> >>> New log begin <<<
>
> 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? If not, are things any different if it is included?

> It seems that the Proxy-Authorization header is sent. However, the
> proxy server doesn't seem to accept it.

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 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. 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.

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).

Kind Regards

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-09-01