linux – 带有cURL的NTLM返回401

目标：连接到Exchange服务器(EWS)
方法：cURL
问题：无法获得身份验证(NTLM),请求返回401.1

似乎有一个陈旧的,有据可查的2问题,从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)
>不应该被链接的bug所困扰,如上所述.
>但受影响,正如我得到401的事实所示

我不确定如何解决这个问题.我可以找到许多旧的(主要是2010年)对这个问题的引用,但没有什么新东西,当然也没有解决问题.我知道提供的引用(参见2)表明这可能适用于旧版本(7.19),但我无法(也不愿意)降级到该版本.

Exchange通信(EWS)的几个实现使用cURL来检索EWS文件(wsdl等),所以我确信必须有一个工作方法,但我找不到它.有谁知道我能做什么？我是否还有另一个错误,我是否解释了错误的事实,这是否仍然与链接中提供的情况相同,并且永远无法解决？

1错误是这样的：

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,Server hello (2):
* SSLv3,CERT (11):
* SSLv3,Server finished (14):
* SSLv3,Client key exchange (16):
* SSLv3,TLS change cipher,Finished (20):
* SSLv3,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):

例如2：

> https://bugs.launchpad.net/ubuntu/+source/curl/+bug/675974
> https://bugzilla.redhat.com/show_bug.cgi?id=603783
> https://stackoverflow.com/questions/4341368/curl-always-returns-401-with-ntlm

>这是同样的问题,但没有解决我的OpenSSL libcurl中不应出现NSS问题的事实.

卷曲信息：

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

解决方法

我不确定为什么,但是虽然我的7.22版本不应该受到整个NTLM问题的影响,但似乎确实如此.

唯一的解决方案似乎是使用旧的(< 7.19,我试过7.15)版本或使用新版本(我试过7.26).如上所述,我不能仅为此功能降级或升级libcurl本身.这意味着我们需要找到一个解决方法.... 使用的解决方法(警告：黑客即将到来)
>下载并编译您想要使用的卷曲.我没有以root身份执行此操作// sudo this因为我不想替换当前的libcurl等！

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

>测试我们刚刚编译的新curl命令：它确实给出了401,但是后来代替gss_init_sec_context()你应该看到它到达(最后)302.这是胜利.
>黑客部分：在调用脚本时使用此libcurl.我们正在使用第三方PHP“应用程序”(我不喜欢更改所有curl库的原因之一),而不是直接调用它,我们制作一个丑陋但工作的包装器,调用这样的东西：

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

是的,这有缺点,是的,这是一个骨架的例子(意味着你可能想要添加一些东西,比如可能是原始路径),但基础有点在那里.

并不为此感到骄傲,但我认为更多的人会因为他们不能将他们的libcurl更新为随机版本并使用某种插件来限制他们使用,例如php-ews,或任何基于NTLMSoapClient构建的东西.

我希望还有另一个选择,但是因为这是目前让它“正常工作”的唯一方法,我想我会分享.

linux – 带有cURL的NTLM返回401

解决方法

相关推荐