带有 cURL 的 NTLM 返回 401

Question

目标：连接到Exchange服务器（EWS）
方法：卷曲
的问题：无法获得认证（NTLM），请求返回401 ¹

似乎有一个古老的、有据可查的²问题始于 cURL 从 OpenSSL 到 NSS 的转移。我读到 NTLM 的实现依赖于 OpenSSL，因此这一举动破坏了 NTLM 身份验证。

问题如下所示，但重要的部分似乎是返回的401和gss_init_sec_context()下面的部分。

我不明白的是我当前的版本：

• 根据https://launchpad.net/ubuntu/+source/curl/7.22.0-3ubuntu4有一个 OpenSSL 变体
• 根据同一个链接支持 NTLM
• 实际上根据下面的日志使用了这个变体（而不是 NSS）（它说libcurl/7.22.0 OpenSSL）
• 根据上述几点，不应受到链接错误的困扰。
• 但受到影响，正如我得到 401 的事实所示

我不确定如何解决这个问题。我可以找到很多关于这个问题的旧（主要是 2010 年）参考，但没有什么新的，当然也没有解决方案。我知道提供的参考资料（参见²）表明这可能适用于旧版本（7.19），但我无法（也不愿意）降级到该版本。

交换通信 (EWS) 的几个实现使用 cURL 来检索 EWS 文件（wsdl 等），所以我确信必须有一种工作方法，但我找不到它。有谁知道我能做什么？我是否有另一个错误，我是否对事实的解释有误，这是否仍然与链接中提供的情况相同并且永远不会修复？

---

¹错误是这样的：

curl https://*DOMAIN*/Exchange.asmx -w %{http_code} --ntlm -u *USERNAME* --verbose --show-error
Enter host password for user '*USERNAME':
* About to connect() to DOMAIN port 443 (#0)
*   Trying IP... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES128-SHA
* Server certificate:
     *SNIP*
*        SSL certificate verify ok.
* Server auth using NTLM with user 'USERNAME'
> GET /EWS/Exchange.asmx HTTP/1.1
> Authorization: NTLM *snip*
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: DOMAIN
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: Microsoft-IIS/7.5
< Set-Cookie: exchangecookie=xxx; expires=Wed, 17-Jul-2013 07:45:30 GMT; path=/; HttpOnly
< WWW-Authenticate: NTLM  *SNIP*
* gss_init_sec_context() failed: : Credentials cache file '/tmp/krb5cc_1005' not foundWWW-Authenticate: Negotiate
< X-Powered-By: ASP.NET
< Date: Tue, 17 Jul 2012 07:45:30 GMT
< Content-Length: 0
<
* Connection #0 to host DOMAIN left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

---

²例如：

• https://bugs.launchpad.net/ubuntu/+source/curl/+bug/675974
• https://bugzilla.redhat.com/show_bug.cgi?id=603783
• /sf/ask/303895791/
  • 这是同样的问题，但没有解决这个NSS问题不应该出现在我的OpenSSLlibcurl 中的事实。

---

卷曲信息：

user@server:~$ curl -V
curl 7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

Answer 1

我不太清楚为什么，但虽然我的 7.22 版本不应该受到整个 NTLM 问题的影响，但似乎确实如此。

唯一的解决方案似乎是使用旧版本（<7.19，我尝试过 7.15）或使用新版本（我尝试过 7.26）。如前所述，我不能仅仅为了这个功能而降级或升级 libcurl 本身。这意味着我们需要找到解决方法......

使用的解决方法（警告：即将出现黑客攻击）

1. 下载并编译您想要使用的curl。我没有以 root 身份执行此操作 //sudo这是因为我不想替换当前的 libcurl 等！

   wget http://curl.haxx.se/download/curl-7.26.0.zip
   ./configure --prefix=/local_path/
   make
   make install
   

2. 测试我们刚刚编译的新curl命令：它确实给出了 401，但是gss_init_sec_context()您应该看到它（最终）变为 302，而不是 302。这就是胜利。

3. 黑客部分：libcurl在调用脚本时使用它。我们正在使用第 3 方 PHP“应用程序”（这是我不高兴更改所有curl 库的原因之一），我们不是直接调用它，而是制作一个丑陋但有效的包装器，它调用类似这样的东西:

   $se = shell_exec("LD_LIBRARY_PATH=/local_path/lib php /path/3rdparty.php");
   

是的，这有缺点，是的，这是一个骨架示例（这意味着您可能想添加一些东西，例如原始路径），但基础知识就在那里。

对此并不感到自豪，但我认为更多的人受到这样一个事实的限制：他们不能直接将其更新libcurl为随机版本，而是使用某种使用例如php-ews或基于NTLMSoapClient.

我希望以后还有另一种选择，但由于这是目前使其“发挥作用”的唯一方法，我想我会分享。