2

我正在尝试在 Kerberos 安全性下连接到 Livy REST 服务。在 Linux CentoS 上curl可以正常工作negotiate，在收到 Kerberoskinit票证后，连接通过

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

我尝试使用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

和curl 的 gow 0.8.0 版本：

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 安全性进行这种连接？

4

2 回答 2

0

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

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

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

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

于 2017-06-23T14:41:49.180 回答
0

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

因此，客户端需要计算出服务的名称（预期的 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@<LOCAL_DOMAIN> 的票证。

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

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

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

于 2021-02-12T14:59:36.580 回答