🔗 Client-Squid NTLM 身份验证协议说明
本文档详细介绍了 NTLM 身份验证方案在 Web 代理中的应用机制。
客户端方面，Microsoft Internet Explorer 和 Mozilla Firefox（现已支持所有平台）均支持此功能。
服务器方面，Microsoft Proxy / ISA Server（当然支持）、Squid 2.5 版本（仅 NTLMv1，直到 Squid 2.5STABLE5）以及通过 Apache 1.3 模块 mod_ntlm_winbind（可从 Samba 的存储库获取）均提供支持。
🔗 NTLM 身份验证机制
- 客户端连接并发出请求，不带任何身份验证信息。所有新连接都会发生这种情况，这与大多数 Basic 身份验证实现不同，后者在成功执行身份验证后会自动为所有连接提供身份验证信息。
- 服务器返回 407 状态码，以及一个头部：
Proxy-Authenticate: NTLM未指定领域、域或其他任何信息。当然，可能还会提供额外的 Proxy-Authenticate 头部来声明其他支持的身份验证方案。所有版本的 Microsoft Internet Explorer 存在一个 Bug，即 NTLM 身份验证方案 **必须** 先声明，否则将无法选中。这违反了 RFC 2616 的规定，该规定称“用户代理 **必须** 选择使用其理解的最强身份验证方案”，而 NTLM 尽管存在许多缺陷，但仍然比 Basic 强大得多。 - 此时，Squid 会断开连接，迫使客户端重新发起连接，无论客户端是否有保持活动（keep-alive）指令。这是一个 Bug 兼容性问题。HTTP/1.1 可能不需要这样做，但无法确定。
- 客户端重新连接并发出 GET 请求，这次附带一个
Proxy-Authorization: NTLM some_more_stuff头部，其中 some_more_stuff 是一个 base64 编码的协商（negotiate）数据包。服务器再次回复 407（“需要代理身份验证”）状态码，以及一个头部：Proxy-Authenticate: NTLM still_some_more_stuff，其中 still_some_more_stuff 是一个 base64 编码的挑战（challenge）数据包。挑战随机数（nonce）包含在这个数据包的某个位置。从这里开始，保持 TCP 连接的活动至关重要，因为所有后续的身份验证相关信息都与 TCP 连接绑定。如果连接中断，身份验证将回到原点。 - 客户端发送一个新的 GET 请求，附带一个头部：
Proxy-Authenticate: NTLM cmon_we_are_almost_done，其中 cmon_we_are_almost_done 是一个身份验证（authenticate）数据包。该数据包包含用户名、域的信息，以及用用户密码编码的挑战随机数（实际上，它 **可能** 包含用不同算法对挑战随机数进行 **两次** 编码的信息）。 - 服务器要么通过 407/DENIED 或 403/DENIED 返回代码拒绝身份验证，我们又回到原点；要么返回请求的资源。从现在开始，只要 TCP 连接保持活动，客户端就不会再向代理发送任何凭据。TCP 连接被标记为“OK”，客户端期望可以发送任何它想要的内容。
🔗 另请参阅
类别： 知识库
导航： 站点搜索、站点页面、类别、🔼 向上