kerberos：客户端如何知道请求票证的服务名称？
kerberos: how the client knows the service name to request ticket to?
让我们假设客户端想要向 HTTP 代理验证自己的身份。代理配置了 kerberos，并且在其配置中明确设置了服务名称 HTTP/proxy.foo.bar。客户端如何知道向哪个服务名称请求票证？它是否请求他正在请求的域名的票证（在这种情况下它确实是 proxy.foo.bar），或者它是否收到身份验证序列中的名称，在这种情况下的 407 回复中（其中不包含协商挑战，但我只是不知道是否有办法调查它）？
我正在尝试调试突然停止验证一些 客户端的代理上的 kerberos 错误。问题是，在 Wireshark 中，我看到客户端请求的票证不是针对在代理上配置的服务名称（他被指示使用的名称相同），HTTP/proxy.foo.bar，但对于代理 IP 解析为的名称，HTTP/host.foo.bar（好吧，至少它是代理解析为，可能是客户端以某种其他方式获取它），而 TGS 找不到一个，因此发生错误。
所以你在这里有两个问题（你没有问如何实际解决问题，要做到这一点需要更多的细节 - 见评论）。
- 您问“代理配置了 kerberos，并且在其配置中明确设置了服务名称 HTTP/proxy。foo.bar。客户端如何知道哪个服务名称申请机票到?"
一个。它的工作原理与此非常相似。客户端在 Web 浏览器中键入 URL 或单击超链接。它在 DNS 域中查找与 URL 中的主机名相匹配的 IP 主机。然后它转到该 IP 主机，寻找 URL 中定义的服务，在本例中它是 HTTP 服务。如果它收到来自 Web 服务器的 HTTP 401 协商质询（它是 401，而不是 407），由于它受 Kerberos 保护，它会转到其 KDC 并请求 HTTP/proxy.[=33= 的 Kerberos 服务票证], 压缩回 proxy.foo.bar 并向该主机提供 HTTP 服务 运行 的票据。主机验证此票证，如果一切正常，客户端 Web 浏览器将呈现 HTML。当您在客户端上 运行 klist 时，您已经看到了 Kerberos 票证。我没有任何网络参考资料给你，这些都是我想不到的。
- 您还问“它是否请求他正在请求的域名的票证（在这种情况下它是代理。foo.bar 确实如此），或者它是否收到名称身份验证序列，在本例中为 407 回复（其中不包含协商挑战，但我只是不知道是否有办法查看它）？”
一个。您的问题有点难以理解，但如果我理解正确的话，答案是 Web 客户端请求票据作为来自 Web 服务器的 HTTP 401 协商身份验证质询的结果（见上文）。
网上有很多图表对这个过程进行排序，包括这里：http://www.zeroshell.org/kerberos/Kerberos-operation/
让我们假设客户端想要向 HTTP 代理验证自己的身份。代理配置了 kerberos，并且在其配置中明确设置了服务名称 HTTP/proxy.foo.bar。客户端如何知道向哪个服务名称请求票证？它是否请求他正在请求的域名的票证（在这种情况下它确实是 proxy.foo.bar），或者它是否收到身份验证序列中的名称，在这种情况下的 407 回复中（其中不包含协商挑战，但我只是不知道是否有办法调查它）？
我正在尝试调试突然停止验证一些 客户端的代理上的 kerberos 错误。问题是，在 Wireshark 中，我看到客户端请求的票证不是针对在代理上配置的服务名称（他被指示使用的名称相同），HTTP/proxy.foo.bar，但对于代理 IP 解析为的名称，HTTP/host.foo.bar（好吧，至少它是代理解析为，可能是客户端以某种其他方式获取它），而 TGS 找不到一个，因此发生错误。
所以你在这里有两个问题（你没有问如何实际解决问题，要做到这一点需要更多的细节 - 见评论）。
- 您问“代理配置了 kerberos，并且在其配置中明确设置了服务名称 HTTP/proxy。foo.bar。客户端如何知道哪个服务名称申请机票到?"
一个。它的工作原理与此非常相似。客户端在 Web 浏览器中键入 URL 或单击超链接。它在 DNS 域中查找与 URL 中的主机名相匹配的 IP 主机。然后它转到该 IP 主机，寻找 URL 中定义的服务，在本例中它是 HTTP 服务。如果它收到来自 Web 服务器的 HTTP 401 协商质询（它是 401，而不是 407），由于它受 Kerberos 保护，它会转到其 KDC 并请求 HTTP/proxy.[=33= 的 Kerberos 服务票证], 压缩回 proxy.foo.bar 并向该主机提供 HTTP 服务 运行 的票据。主机验证此票证，如果一切正常，客户端 Web 浏览器将呈现 HTML。当您在客户端上 运行 klist 时，您已经看到了 Kerberos 票证。我没有任何网络参考资料给你，这些都是我想不到的。
- 您还问“它是否请求他正在请求的域名的票证（在这种情况下它是代理。foo.bar 确实如此），或者它是否收到名称身份验证序列，在本例中为 407 回复（其中不包含协商挑战，但我只是不知道是否有办法查看它）？”
一个。您的问题有点难以理解，但如果我理解正确的话，答案是 Web 客户端请求票据作为来自 Web 服务器的 HTTP 401 协商身份验证质询的结果（见上文）。
网上有很多图表对这个过程进行排序，包括这里：http://www.zeroshell.org/kerberos/Kerberos-operation/