Question

我正在尝试连接到Kerberos安全性下的Livy REST服务。在Linux CentoS curl上收到Kerberos negotiate票证后通过<{p}}可以正常使用kinit

curl --negotiate -u : http://service_link

我面临的问题是尝试在远程Windows桌面上执行相同的操作。我正在使用MIT Kerberos for Windows，它能够成功kinit。但是，curl似乎正在协商使用NTLM SSL票证而不是Kerberos，这会导致以下错误：

AuthenticationFilter: Authentication exception: org.apache.hadoop.security.authentication.client.AuthenticationException

我已尝试使用official curl release for windows，具有这些功能（curl --version）：

Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy

和gow 0.8.0 version of curl：

Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM SPNEGO SSL SSPI libz

这两个都在谈判时使用NTLM SLL。

问题：有没有办法强制使用Kerberos而不是NTLM？是否可以调试谈判者以查看它是否（以及在哪里）寻找Kerberos（可能还没有看到）票证？

关于Kerberos，似乎是在其api上存储了keytabs，所以我将KRB5CCNAME环境变量设置为API:Initial default ccache; klist能够查看故障单，但是，curl可能需要额外的规范吗？

此外 - 是否有curl替代Kerberos安全性的方法？

Answer 1

http://service_link是Kerberos的愚蠢网址。由于这是一个标签名称，客户端只会在其默认领域中查找服务票证。最好使用和FQDN，以便可以解析主机并将域部分与域匹配。

此外，您的帖子中没有提及SPN。如果curl可以猜出要与之通信的正确KDC，则需要在Web服务器上运行auth的帐户上注册的SPN HTTP / service_link。

最后，您是否使用Fiddler等确认您的Web服务器正在发回WWW-Authenticate：negotiate标头？ curl确实有代理设置。

如果所有设置都不正确，则无法强制使用Kerberos。如果他们是对的，curl将首先尝试并成功。根据错误，它可能会尝试Curb然后恢复为NTLM。

Answer 2

服务的名称及其相应的 SPN 对于理解 Kerberos AUTH 至关重要，并且可能非常棘手。要理解这个问题，您应该了解从 Web 服务器（或代理）返回的 Challenge 本质上是“我喜欢 Kerberos，给我一张票”……Web 服务器没有提供关于它会提供什么票的提示准备接受，也没有告诉客户如何获得合适的。

因此，客户端需要计算出服务的名称（预期的 SPN），然后它需要一个 Kerberos 配置来告诉它如何获取合适的票证（如果不是从其本地 Kerberos 域）。

>

因此，对于访问 http://www.github.com/ 的客户端，SPN 将是 HTTP/www.github.com，但客户端首先需要检查该名称以了解其解析方式。它实际上是一个通过 github.com 解析的 CNAME，然后实际的 SPN 将是 HTTP/github.com - 然后客户端需要检查其 Kerberos 配置以查看该名称是否在外部 Kerberos 域中（这增加了额外的复杂性）。对于本地 kerberos 域，客户端将向其本地 Kerberos 票证授予服务提供 krbtgt/ @，请求 SPN HTTP/github.com @ 的票证。

如果在本地 Kerberos 票证授予服务中注册了 SPN，则它会发出票证，然后客户端将其呈现给网站。网站将接受它，前提是它具有正确的 SPN 和正确的发行域。

如果您连接的 Web 服务实际上是 github.com 的本地假冒产品，并且接受来自您本地域的票证，那么这可以工作。但是对于您自己本地环境之外的网站，外部 Kerberos 域、配置和信任关系的额外复杂性将发挥作用。

即使在您的本地环境中，客户端也需要能够从用于访问目标资源的名称中派生出正确的 SPN，并且该 SPN 需要注册并与 Web 服务相关联（以便它可以解密 Kerberos出示门票时）。

curl：如何在Windows上使用Kerberos而不是NTLM身份验证？

2 个答案: