从根本上讲，Kerberos 并不是一个过于复杂的协议。我还已成功配置了一台服务器，使其通过 SPNEGO HTTP 标头接受 Kerberos 身份验证。不过，我是这个领域的新手，所以也许我忽略了一些东西……
令人困惑的部分Kerberos 及其实现是选修的客户端在将生成的 SPN 发送到 KDC 之前对服务器的主机名进行反向 DNS 查找，以便获取由该 SPN 标识的服务器/应用程序的票证。因此，客户端可以使用最初请求的主机名（这可能是一个别名 - CNAME)，或者在生成的 SPN 中反向查找 IP 地址所属服务器的名称。这会使 Kerberos 设置变得非常复杂。
Kerberos 规范（RFC 4120）似乎倾向于避免反向查找（也称为“规范化”）：
1.3. 选择要通信的主体
...
实现注意事项：许多当前实现都会对提供的服务名称进行一定程度的规范化，通常使用 DNS，尽管这会带来安全问题。但是， 对于服务名称是 大小写折叠为小写还是使用反向解析，实现之间
并不一致。为了 最大限度地提高互操作性和安全性，应用程序应提供 安全机制，其名称是将用户输入的名称折叠 为小写，而不执行任何其他修改 或规范化。
例如，广泛使用的 MIT Kerberos 实现提供了禁用反向查找的选项，甚至有几种场景建议何时应禁用反向查找，例如他们的文件。另一方面，在 Windows 中，反向查找似乎是硬编码的（参见相关问题在 Windows 上全局禁用 Kerberos 的反向 DNS 查找？）。
问题反向查找不仅会破坏服务器别名 (CNAMES) 的使用，而且当同一台机器上的不同程序决定以不同的方式处理它时，它们的可选性可能会导致真正意想不到且不稳定的行为。例如当Fiddler 使 Kerberos 身份验证正常工作。并且从我的测试来看，与 Chrome 或 IE 不同，当前的 Firefox 甚至会在请求的主机名与使用的 Kerberos 客户端库查找的主机名不匹配时拒绝向服务器发送 Keberos 令牌。
那么问题来了：为什么Kerberos 客户端是否存在这种最有问题的默认行为？有没有真实的如今受益除了在未提供 FQDN 时获取服务器的 FQDN 或“向后兼容”之外，是否可以通过执行反向查找来获取？被调用服务器的身份是否可以通过 SSL 的广泛使用得到某种程度的确认？
附加问题：没有新的标准来应对这个 Kerberos“怪癖”吗？
答案1
我一直以为这是为了破坏 CNAMES。
答案2
我想这可能是为什么我的 keberoized 应用程序在 Windows 环境中运行良好（仅使用 CNAME 的一个 SPN），但在 Unix 环境中运行该应用程序需要另一个主机名的 SPN。