curl:如何在 Windows 上使用 Kerberos 而不是 NTLM 身份验证?
Posted
技术标签:
【中文标题】curl:如何在 Windows 上使用 Kerberos 而不是 NTLM 身份验证?【英文标题】:curl: how to use Kerberos instead of NTLM authentication on Windows? 【发布时间】: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 安全性的这种连接?
【问题讨论】:
【参考方案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门票)。
【讨论】:
以上是关于curl:如何在 Windows 上使用 Kerberos 而不是 NTLM 身份验证?的主要内容,如果未能解决你的问题,请参考以下文章
如何在 Xampp Windows 10 上重新安装 PHP cURL?