apache - 为什么不同域中的浏览器根本不响应 mod_auth_kerb 发送的 "WWW Authenticate : Negotiate" header ？

Question

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

我从两台客户机请求了一个受 Kerberos 保护的页面，一个用户属于 Kerberos-setup 域，另一个用户属于某个其他域。
然后我比较了两台机器上的 HTTP 数据包。在两台机器上，在发送对 Kerberos 保护页面的请求后，服务器会使用以下 HTTP 数据包进行响应:
需要 HTTP/1.1 401 授权
日期:格林威治标准时间 2012 年 9 月 5 日星期三 14:25:20
服务器:Apache WWW-认证:协商
WWW-Authenticate: Basic realm="Kerberos Login"
内容长度:60
连接:关闭
内容类型:文本/html；字符集=iso-8859-1

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

现在我的理解是，属于另一个域的客户端也应该用它自己的 TGT+Session key token 进行响应，事件目录应该拒绝它。但是为什么这个客户端根本不响应服务器的 WWW-Authenticate : Negotiate 挑战超出了我的逻辑。
更令人困惑的是，服务器的 HTTP 响应(如上所示)不包含有关它链接到的域的任何信息。

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

注意:两台客户端机器都有 Windows 7，事件目录是 Windows 2008 服务器。

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

Answer 1

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

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