Question

当kerberos不可用时，我希望libcurl回退到NTLM。

我正在使用此设置，

// explicit
curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, CURLAUTH_NTLM | CURLAUTH_GSSNEGOTIATE);
// or any
curl_easy_setopt(_curl, CURLOPT_HTTPAUTH, CURLAUTH_ANY);

实际发生的是服务器发送支持的方案

<= recv header: HTTP/1.1 401 Unauthorized
<= recv header: Content-Length: 0
text: Server Microsoft-HTTPAPI/2.0 is not blacklisted
<= recv header: Server: Microsoft-HTTPAPI/2.0
<= recv header: WWW-Authenticate: Negotiate
<= recv header: WWW-Authenticate: NTLM

但客户端只发送一个Negotiate令牌

text: Server auth using GSS-Negotiate with user ''
=> send header: POST /daas/services/hello HTTP/1.1
Authorization: Negotiate YHkGBisGAQUFAqBvMG2gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xI...TC1NT0JMR0VS
User-Agent: libcurl-agent/1.0
Host: localhost:8008
Accept: */*
Content-Length: 328
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------19e8c490d70b39c1
....

由于我还没有定义SPN，我希望NTLM后备能够正常工作，但我得到了这个

<= recv header: HTTP/1.1 401 Unauthorized
<= recv header: Content-Length: 0
text: Server Microsoft-HTTPAPI/2.0 is not blacklisted
<= recv header: Server: Microsoft-HTTPAPI/2.0
text: Authentication problem. Ignoring this.
<= recv header: WWW-Authenticate: Negotiate oYIBHDCCAAAAPRwBFAFIAAgAEA.....BvAG0ABQAcAGMAb
<= recv header: Date: Fri, 26 Sep 2014 16:16:24 GMT
text: HTTP error before end of send, stop sending
<= recv header:
text: Closing connection 2

我认为客户端应该发送几个可能的令牌，并让服务器选择要回答的内容。

任何想法？

Answer 1

没有;客户端应该发送最佳机制，它不应该发送所有机制。

这些机制不是＆＃34;后退＆＃34;在某种意义上说，如果一个机制失败，它将尝试第二个，然后是第三个，等等。对于服务器宣传它支持谈判的情况，这将是一个错误优化，但事实上并非如此。这将转变为：

Server: Hi, I suppose Negotiate, NTLM, Digest and Basic
Client: Okay, here's some Negotiate credentials
Server: Sorry! Either your credentials do not authenticate you, or whomever you authenticated as does not have authorization to view this page.
Client: Okay, well, what if I give you the same credentials, only in NTLM form
Server: What difference does that make?  You still can't come in.
Client: What about Digest?
Server: What do you mean, digest?  What makes you think that if I rejected your Negotiate and your NTLM credentials that suddenly your digest credentials will be any different?
Client: Well, here's the same credentials with Basic
Server: Okay, seriously, just go away.

简单地说，您的服务器配置不正确：如果您宣传Negotiate，客户将提供协商凭据，期望您可以支持它们。客户将不回退到其他方案，希望这些方案得到支持。

Answer 2

我实际上已经注册了libcurl邮件列表并且得到了相当快的答案，

响应如下，

我正在尝试使用libcurl连接到支持的Web服务器两者，但有些客户不能做kerberos。

当你说某些客户不能做Kerberos你是什么意思，你有什么限制阻止这种使用？这是一个限制，意味着libcurl不能或不应该使用Kerberos吗？

我将CURLOPT_HTTPAUTH设置为CURLAUTH_GSSNEGOTIATE | CURLAUTH_NTLM

a）您使用的是什么版本的libcurl？从输出看起来它看起来像7.38.0之前的版本 - 如果是这种情况你可能想要忽略我的问题，包括本节并跳转到我关于升级的评论;-) b）你使用什么平台？ Windows，Linux等...... c）如果您使用的是Windows，您使用的是针对Windows SSPI编译的libcurl版本还是使用GSS-API库编译的版本（例如MIT Kerberos或Heimdal）？

libcurl应该回退到NTLM吗？

没有...

不幸的是，我不是我们的HTTP专家之一，所以我可能在这里错了，但我会尝试用我的curl认证帽和一些有限的HTTP知识回答这个问题; - ）

我的理解是，如果Kerberos失败，Negotiate（SPNEGO）身份验证机制将尝试执行Kerberos，然后回退到NTLM，作为与服务器通信的一部分。因此，您只能分别从客户端和服务器看到“WWW-Authorization：Negotiate”和“WWW-Authenticate：Negotiate”标题，而不是之前和“WWW-Authorization：NTLM”和“WWW-Authenticate：NTLM”的组合。 ”

因为这样的libcurl本身不需要做后退，因为SPNEGO通信将为我们处理它; - ）

我做错了吗？

我们在7.38.0中解决了与谈判有关的一些问题，主要是：

使用GSS-API库编译时，我们没有使用正确的SPNEGO OID
如果Kerberos失败，则不会执行回退到NTLM
已弃用CURLAUTH_GSSNEGOTIATE并已推出CURLAUTH_NEGOTIATE

因此，我建议你：

升级至7.38.0
使用CURLAUTH_NEGOTIATE而不是CURLAUTH_GSSNEGOTIATE | CURLAUTH_NTLM

将检查并更新......

libcurl协商回退到ntlm

2 个答案: