为什么不同域中的浏览器根本不响应mod_auth_kerb发送的“WWW Authenticate：Negotiate”标头？

Question

我已经在我们的apache-active目录环境中通过mod_auth_kerb实现了SSO，它按预期工作。然而，以下知识让我烦恼：

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

HTTP / 1.1 401授权要求 日期：星期三，2012年9月5日14:25:20 GMT 服务器：Apache WWW-Authenticate：Negotiate WWW-Authenticate：Basic realm =“Kerberos Login” 内容长度：60 连接：关闭 内容类型：text / html;字符集= ISO-8859-1

然而，在服务器的上述响应之后，属于Kerberos-setup域的客户端计算机的浏览器响应 WWW-Authenticate：Negotiate'令牌'，而其他客户端浏览器（属于用户）到其他一些领域）根本没有回应。

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

那么在什么基础上属于正确域的客户端浏览器决定它必须响应服务器的 WWW-Authenticate：Negotiate 挑战，以及客户端属于其他什么的基础域名决定不回应？

注意：两台客户端计算机都具有Windows 7，而活动目录是Windows 2008服务器。

我正在尝试理解mod_auth_kerb的SSO实现，而这一特定知识对此至关重要。

Answer 1

模块启用了选项KrbMethodK5Passwd。它发送一个Basic标头来收集您的Kerberos凭据。这对于非域客户端来说毫无意义。禁用此选项。

auth机制的优势层次，浏览器有义务选择最佳。这是：谈判，摘要，NTLM，基本。