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

【问题标题】：curl: how to use Kerberos instead of NTLM authentication on Windows?curl：如何在 Windows 上使用 Kerberos 而不是 NTLM 身份验证？
【发布时间】：2017-11-26 17:05:57
【问题描述】：

我正在尝试在 Kerberos 安全性下连接到 Livy REST 服务。在 Linux CentoS 上，curl 与 negotiate 可以正常工作，在收到 Kerberos 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？是否可以调试 Negotiator 以查看它是否（以及在哪里）正在寻找 Kerberos（并且可能没有看到）票？

关于 Kerberos，它似乎将 keytabs 存储在它的 api 上，所以我将 KRB5CCNAME 环境变量设置为 API:Initial default ccache； klist 可以看到票，但是，也许curl 需要额外的说明？

还有——有没有curl 的替代方法来实现与 Kerberos 安全性的这种连接？

【问题讨论】：

标签： rest hadoop curl kerberos livy

【解决方案1】：

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

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

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

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

【讨论】：

感谢您的回复，因其他问题而脱轨，所以只投了赞成票。
服务链接很愚蠢，因为我通过 ssh 隧道连接到它，尽管在 hosts 中更改它并没有帮助。不是通过 Fiddler，而是通过curl 中的--verbose 我可以看到服务器正在发回协商标头。所以我最好的猜测是问题在于 SPN HTTP/service_link 正确注册，因为我不熟悉它并且可能缺少一些设置。

【解决方案2】：

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

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

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

如果 SPN 在 Local Kerberos Ticket Granting 服务中注册，那么它将发出 Ticket，并且客户端将其呈现给 Web 站点。网站将接受它，前提是它具有正确的 SPN 和正确的发布域。

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

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

【讨论】：