Apache 为什么不同域中的浏览器根本不响应；WWW.Authenticate:Negotiate"；标题由mod_auth_kerb发送？

我已经在apache active directory环境中通过mod_auth_kerb实现了SSO，它的工作原理与预期一样。然而，以下知识困扰着我：

我从两台客户机请求了一个受Kerberos保护的页面，一个用户属于Kerberos设置域，另一个用户属于其他域。 然后我比较了这两台机器上的HTTP数据包。在这两台机器上，发送Kerberos保护页请求后，服务器将使用以下HTTP数据包进行响应：

需要HTTP/1.1 401授权 日期：2012年9月5日星期三14:25:20 GMT 服务器：Apache WWW身份验证：协商 WWW-Authenticate:Basic-realm=“Kerberos登录” 内容长度：60 连接：关闭 内容类型：text/html；字符集=iso-8859-1

但是，在服务器发出上述响应后，属于Kerberos设置域的客户端计算机的浏览器将使用WWW-Authenticate:Negotiate“token”进行响应，而其他客户端浏览器（属于其他域的用户）则根本不响应

现在我的理解是，属于另一个域的客户端也应该使用自己的TGT+会话密钥令牌进行响应，而active directory应该拒绝该令牌。但是，为什么这个客户机根本不响应服务器的WWW-Authenticate:congregate挑战超出了我的逻辑。 更令人困惑的是，服务器的HTTP响应（如上所述）不包含任何有关其链接到的域的信息

那么，属于正确域的客户端浏览器根据什么决定必须响应服务器的WWW-Authenticate:agreement质询，以及属于其他域的客户端根据什么决定不响应相同的质询

注意：两台客户端计算机都有Windows 7，active directory是Windows 2008服务器

---

我试图了解mod_auth_kerb的SSO实现，而这一特定知识是实现SSO的关键。

模块已启用选项

KrbMethodK5Passwd

。它发送一个基本头来收集Kerberos凭据。这对于非域客户机来说毫无意义。禁用此选项

---

身份验证机制有一个层次结构，浏览器必须选择最好的。这是：协商、摘要、NTLM、基本。

请更正您的问题。是否与来自不同域的用户或不属于某个域的用户有问题？@Michael-O我的问题中的用户属于不同域。我已经编辑了我的问题以便更清晰。我知道KrbMethodK5Passwd已打开，这就是非域浏览器弹出询问登录凭据的原因。我不明白的是，为什么这个非域浏览器不使用它自己的TGT+会话密钥令牌（如域浏览器）进行响应，并让active directory决定令牌是否属于它的一个用户。非域浏览器在什么基础上决定不响应服务器的WWW身份验证：协商？域浏览器根据什么决定响应相同的请求？您的浏览器不响应，因为没有域信任。你必须先确定这一点。如果这样做，您就可以轻松地执行跨领域身份验证。请参阅KDC配置文档。对于chrome，需要在安全策略（ADM）中添加身份验证白名单，以便允许它发送令牌或协商SPNEGO挑战。@JalalSordo哪个chrome从注册表读取Windows上的默认白名单。（内联网区域）@JalalSordo No，一份声明。