Java HTTP NTLM 实现差异答案

【问题标题】：Java HTTP NTLM Implementation DifferencesJava HTTP NTLM 实现差异
【发布时间】：2011-08-22 13:40:50
【问题描述】：

link 详细介绍了各种 http 客户端 java 实现。我正在寻找任何可以提供有关其 NTLM 协议实现差异信息的链接。

在其中一台 Windows 机器上，我发现 commons-http 客户端 3.1 实现失败并出现授权错误（http 状态代码 401），但 java 1.5 实现成功。由于 NTLM 身份验证协议的 java 1.5 实现不是开源的，因此我无法比较这两种实现以了解可能出现的问题。

更新 1

我知道 commons http 客户端不支持 NTLM v2。这个link 提供了各种java http 客户端实现之间的比较，并提到apache http 客户端提供了NTLM 协议的部分实现。它没有详细说明。

在进一步解决问题时，我还发现this link 结合HTTPClient 提供的 NTLM 实现在 windows 机器上工作（正如我上面提到的那样，commons http 客户端实现不起作用）。

更新 2

通过嗅探数据包（使用wirehack），我意识到commons http 客户端3.1 ntlm 协议实现不会在Type 3 消息中生成NTLM 响应。这是由 JDK 实现生成的。您是否知道任何服务器/客户端设置表明如果 NTLM 响应数据为空，则身份验证将失败？（因为我们面临的身份验证失败只能在一台机器上重现。身份验证在其他地方成功。）

【问题讨论】：

标签： java windows ntlm apache-commons-httpclient

【解决方案1】：

Commons httpclient 3.1 没有实现 NTLMv2，它只实现了旧的 NTLM（又名 NTLMv1）规范。

【讨论】：

对。但这似乎不是我提到的 Windows 机器的问题，因为使用浏览器（Internet Explorer）访问资源是可行的。该机器上的 HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel 为 2，表示浏览器使用 NTLM v1。
我想我明白你在说什么，但我不认为 LmCompatibilityLevel 是这里的保证。尤其是因为这只对 NTLM 设置有影响，而对 SPNEGO 没有影响。您是否使用过 Wireshark 来确定 IE 发送的内容？我怀疑它不是 NTLMv1。有关 LmCompatibilityLevel 及其限制的详细讨论，请参阅 technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx（很遗憾，它没有讨论 Kerberos/SPNEGO。）
您的意思是即使客户端和服务器机器上的LmCompatibilityLevel级别为2，使用NTLMv2的情况仍然可能发生？我无权访问域控制器的注册表项来验证其 LmCompatibilityLevel 的值。我会看看并确认这一点。我使用 HTTPAnalyzer 来捕获 HTTP 请求，该请求没有详细说明正在使用的 NTLM 版本。我将尝试 Wireshark 并跟进。非常感谢您的回复。
我在wireshark上查看了详细信息。我没有找到方法来确认是使用 NTLMv1 还是 NTLMv2。在进行更多故障排除时，我意识到 Type 3 消息中的 NTLM 响应不是由 commons httpclient 3.1 生成的，而是由 NTLM 协议实现的 JDK 实现生成的。不确定这是否是问题的原因。此处发布的另一个问题 - stackoverflow.com/questions/916820/… 在答案中也提到了它，但没有足够的细节。如果您对此有任何详细信息，请告诉我。谢谢
如果没有第 3 类响应，NTLM 身份验证肯定会失败。您可以查看标志以查看响应中是否设置了（或未设置） NEGOTIATE_NTLM2 标志。至于另一个问题，我没有使用 JCIFS 代码来生成 NTLM 响应。但 NTLM2 的规范可从 Microsoft 获得：msdn.microsoft.com/en-us/library/cc236621(v=PROT.13).aspx

【解决方案2】：

我们找到了这个问题的根本原因。导致身份验证错误的配置设置由名为 NoLMHashPolicy 的安全策略控制。启用此策略意味着 Windows 服务器将不再存储任何密码的 LM 哈希值，它将使用 NT 响应哈希进行身份验证。由于来自 commons http 客户端 3.1 库的 NTLM 协议实现根本不计算 NT 响应，因此启用此设置时可能会遇到此错误。有关此设置的更多详细信息，请参阅here。

作为一种解决方案，可以只添加 AuthScheme 接口的实现，并从更高版本的公共 http 客户端库（例如 4.1.2）中提取代码，该库计算类型 3 消息中的 NT 响应。不要忘记更新 NT 响应字段的长度和偏移值。一旦 AuthScheme 接口的实现准备就绪，就可以使用 AuthPolicy.registeryScheme() 方法进行注入。

【讨论】：