Hide Forgot
+++ This bug was initially created as a clone of Bug #1154747 +++ Description of problem: if CURLOPT_FORBID_REUSE is set, requests using NTLM failed since NTLM requires multiple requests that re-use the same connection for the authentication to work Version-Release number of selected component (if applicable): 7.19.7 How reproducible: The connection of NTLM authenticated request shouldn't be reuse in libcurl multi interface because it includes authentication context, after reuse with other plain requests to the same server, the context will be messed up and then next request with the same user's NTLM authentication will get 401 always until this connection get closed by HTTP server, and new connection to be established for the NTLM request. But because of this defect, I couldn't set CURLOPT_FORBID_REUSE for NTLM authenticated request (it always failed after retry five times), due to NTLM requires the same connection for at least two continuous requests to finish authentication. This issue normally may not be able reproduce with curl command line because curl doesn't use the multi interface for asynchronous I/O that my appserver did. Expected results: Ignore the forbid reuse flag in case the NTLM authentication handshake is in progress, according to the NTLM state flag. Additional info: Please refer to curl fix here. https://github.com/bagder/curl/commit/63a0bd4270decef04e64fbe497b42f2c9e26c62b --- Additional comment from Paul Ling on 2014-10-22 20:51:24 CEST --- Steps to Reproduce: 1. Create curl multi handle with most default options, I only set CURLMOPT_SOCKETFUNCTION/CURLMOPT_SOCKETDATA for libevent integration 2. Create and add easy handle for NTLM authentication HTTPS request with AD user A credentials. One connection will be established this time 3. Create and add one HTTPS request to the same web server but doesn't require NTLM authentication afterward, libcurl will reuse the connection which send NTLM authentication request. 4. Create and add the third request as same as the first NTLM requests with the same user. libcurl still want to reuse the same connection for this new NTLM request. But IIS will return 401 always as below unless the old connection break down and new connection established. * Re-using existing connection! (#0) with host hhh.xxx.com * Connected to hhh.xxx.com (10.26.0.100) port 443 (#0) * Server auth using NTLM with user 'ppp' > POST /auth/useradauth HTTP/1.1^M User-Agent: libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2^M Host: hhh.xxx.com^M Accept: */*^M Content-Type: application/json^M Content-Length: 67^M ^M < HTTP/1.1 401 Unauthorized^M < Server: Microsoft-IIS/7.5^M * gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_0' not found< WWW-Authenticate: Negotiate^M * Authentication problem. Ignoring this. < WWW-Authenticate: NTLM^M < X-Powered-By: ASP.NET^M < Date: Wed, 22 Oct 2014 18:40:44 GMT^M < Content-Length: 0^M < ^M * Connection #0 to host hhh.xxx.com left intact --- Additional comment from Paul Ling on 2014-10-24 23:19:20 CEST --- Let me explain little bit more about my case. My web server has two web apps, one is authenticator which takes IWA authentication and issue my special ticket to client. The second web app is that takes this ticket inside of HTTP body to provide discovery service, this web app does not request NTLM authentication. The client process is that sending authentication HTTPS request with user/password to the first webapp, following by the second NON-NTLM HTTPS request without user/password. Once my client repeat this process, only the first authentication HTTPS request got succeeded, the second time authentication and later will always got 401 failure because of the connection re-use.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-2159.html