如果kinit正在找到KDC，则没有可以影响tomcat的安全策略，那么这两个请求都是

I'，您的Java可能使用的是与默认设置不同的krb5（它的kinit应该位于tomcat指向的Java目录中）。 d始终将krb5保留在C：\ windows中，以避免发生不同的Krb5问题（尽管无论如何这里都可能发生）。 尝试编辑c：\ windows \ krb5.ini并仅放入一个错误的KDC，然后再次测试kinit，如果它有效，则需要找到kinit使用的实际krb5。 在那种情况下，我会搜索硬盘。 在Java中有一个地方可以对其进行硬编码，但我们不建议这样做。

还有其他奇怪的地方是错误本身，通常是"无法获取领域的kdc"，因此tomcat可能存在某种问题，因此实际上并没有使用krb5并引发了虚假错误

还有一件事。 在kinit上，REALM是从krb5默认领域中获取的，而tomcat是从CMC>身份验证> Windows AD>默认域中获取的。 CMC中的领域是否可能是错误的？ 这通常会导致其他错误，但是由于该错误并非真正正确，因此我们也应检查该错误。

-Tim

嗨，蒂姆

SPN现在很好，并且服务帐户有权充当操作系统的一部分。 应用服务器和Web服务器。 我验证了只有一个krb5.ini文件，并且java选项拼写正确并指向正确的位置。 我仍然在屏幕上看到相同的错误消息，并在stdout.log文件中看到"无法找到KDC"。

由于服务器正在运行Windows 2016，因此我还在krb5.ini中尝试了以下操作：

default_tgs_enctypes = aes128-cts-hmac-sha1-96
default_tkt_enctypes = aes128-cts-hmac-sha1-96

但这都不能解决问题。

-Dell

Dell，我认为您最终解决了此问题。 解决方案是什么？

嗨，蒂姆，

我再次验证服务器上只有一个krb5.ini文件。 它在C：\ Windows中。 由于它们具有一些我以前从未见过的奇怪的安全策略，可能会影响此效果，因此将krb5和bscLogin文件移动到单独的文件夹（D：\ WinAD_Config），将Tomcat的Java选项设置为指向正确的文件夹 ，然后重试。 在bscLogin.conf中已经启用了日志记录，但是我使用您指定的java选项为krb5启用了日志记录。 这就是我现在在stdout.log中看到的内容：

 Java配置名称：D：\ WinAD_Config \ krb5.ini
 从Java配置加载
 >>> Kdc辅助功能：重置
 default_tkt_enctypes的默认etypes：23。
 >>> KrbAsReq创建消息
 使用UDP的getKDCFromDNS
 使用TCP的getKDCFromDNS
 [Krb5LoginModule]身份验证失败
 无法找到KDC 
 

所以在我看来，它正在找到正确的krb5.ini文件，但实际上并没有找到KDC。 在这一点上，我很确定问题出在他们所采用的古怪，过于严格的安全策略，或者它们所使用的加密类型不同于rc4-hmac或aes128-cts-hmac-sha1-96。 这对您有意义吗？

-Dell

IIRC，默认AD域或在以下位置配置的服务主体名称有问题 CMC中的身份验证。 但是，那是几个客户之前的事-从那时起我已经为客户完成了三次安装/升级-我不记得确切的问题是什么。

-Dell