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

Question

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

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

HTTP/1.1 401 需要授权日期：2012 年 9 月 5 日星期三 14:25:20 GMT 服务器：Apache WWW-Authenticate : Negotiate WWW-Authenticate: Basic realm="Kerberos Login" Content-Length: 60 Connection: close Content-Type: text/html; 字符集=iso-8859-1

但是，在来自服务器的上述响应之后，属于 Kerberos-setup 域的客户端计算机的浏览器以WWW-Authenticate响应：Negotiate 'token'，而其他客户端浏览器（属于某个其他域的用户）根本不响应.

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

那么属于正确域的客户端浏览器基于什么决定它必须响应服务器的WWW-Authenticate : Negotiate挑战，而属于其他域的客户端基于什么决定不响应相同的请求？

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

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

Answer 1

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

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