On Mon, 01 Sep 2014, Ulrich Telle wrote: > 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.
Okay cool - it will be interesting to see how you get on and what information comes out of that. > 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. Sure - if it is a problem in libcurl I would like to be able to resolve it as well. So any assistance you can provide in identifying the issue would be great. > > I appreciate you have masked the username to protect identities, but > > was the domain specified in the username? > > No. Just the user id. Okay. I could be wrong here but I believe that: a) The SSPI builds when no user name is supplied will use the current user credentials and as such the domain will be included b) If the username is specified in the SSPI build then the domain is optional - if no domain is included then the server should default to one. c) If the non-SSPI build is used then the user has to be specified but the domain is also optional - if no domain is included then the server should default to one just like with b). Do you know if this is a multi-domain/forest setup? Are the 70+ users that you are having difficulty with, in different domains to that of the proxy servers? I've not played around with multi-domains too much myself apart from a little testing here and there so I'm not sure how a server would pick the correct domain to use. From my own testing of GSSAPI (Kerberos v5 authentication) that I've added for the email protocols in the upcoming release, the domain *had* to be included when specifying the username manually but it is optional with NTLM. > > 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 take it both IE and Firefox users are prompted for their credentials and as such single sign-on isn't used? > > 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. In the SSPI code the call to process the type-2 and generate the type-3 is done in a single call InitializeSecurityContext() so from here at least, it is quite difficult to know what failed. Only the base-64 decoding of the message is performed by libcurl in this instance. We would need to examine the "status" variable to have a better idea but I'm guessing there was something in the type-2 that the local machine (that running your app/libcurl) didn't like - whether that is unmatched security settings such as encryption level, a difference in supported protocol versions (NTLM vs NTLMv2 for example) or something else I can't say. > > 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. It's probably not important but it is what I would expect from my limited knowledge of the HTTP code. > > 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 ... Cool - I would also recommend you test the SSPI builds with and without single sign-on support. Also out of interest what Proxy Server software is the client using? Is it the same across all of the servers? > I appreciate your support very much. No problem - hopefully we can get to the bottom of this. Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
