背景：
当用于访问我们的networking服务器的PC绑定到有问题的AD时，我们遇到了一个只有IE或Chrome才能显示的ADnetworking的问题。 没有令牌被传递，并且在与令牌协商相关的服务器日志中没有条目。 如果我们使用Firefox并启用network.negotiate-auth选项，则用户可以毫无问题地login，但是当使用IE时，他们会得到授权所需的错误。 该网站位于Intranet区域，IWA被检查（由GPO控制）
如果用户尝试使用IE或Chrome从AD以外访问该站点，则会出现预期的身份validationlogin提示，然后会正确发送令牌。
我已经和networkingpipe理员说过了，他们确信AD没有特殊的configuration来确保Kerberos身份validation的正常工作，但是我不明白为什么身份validation可以用于其他六个ADnetworking，并且如果不是这样， ADconfiguration本身。
我错过了什么吗？ 什么可以解释谈判令牌的失败？
[注意 – 这不是紧急的，而我现在离开办公室的时候，将会在星期一回答任何关于更多细节的请求]
问题在于，ADnetworking内部正在发送令牌并自动进行协商，但由于生成密钥表时使用了encryption，因此总是失败。
最初我们使用了-crypto DES-CBC-CRC，但是一旦我们改用使用-crypto RC4-HMAC-NT ，问题就消失了。
不是这方面的专家，但我倾向于认为，如果没有谈判令牌正在交换，问题可能在于应用程序未将其SPN注册到密钥表的相关用户名。
如果是这样的话，在AD服务器上运行的以下命令可能会修复它：
setspn -a HTTP /（yourhostname）（keytabusername）
例如setspn -a HTTP / intranetappsrv.mycompany.com jbossaccount