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

Question

我正在尝试连接到Kerberos安全性下的Livy REST服务。在Linux CentoS上，curl可以很好地与negotiate一起使用，在收到Kerberoskinit票证后，连接通过

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

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

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

我尝试使用适用于 Windows 的官方 curl 版本，具有以下功能(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 版本的 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 上，因此我将KRB5CCNAME环境变量设置为API:Initial default ccache;klist能够看到票证，但是，也许curl需要额外的规范？

另外 - 是否有其他方法可以curl与 Kerberos 安全性的此类连接？

Answer 1

服务的名称及其随之而来的 SPN 对于理解 Kerberos AUTH 至关重要，并且可能非常棘手。要理解这个问题，您应该了解从 Web 服务器(或代理)返回的挑战本质上是"我喜欢 Kerberos，给我一张票"......Web 服务器没有提供关于它准备接受哪些票证的提示，也没有告诉客户端如何获得合适的票证。

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

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

如果 SPN 在本地 Kerberos 票证授予服务中注册，则它将签发票证，客户端将向网站出示票证。网站将接受它，只要它有正确的SPN和正确的发行域。

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

即使在本地环境中，客户端也需要能够从用于访问目标资源的名称派生正确的 SPN，并且需要注册 SPN 并将其与 Web 服务关联(以便它可以在显示 Kerberos 票证时对其进行解密)。

Answer 2

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

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

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

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