Java HTTP NTLM 实现差异
此链接详细介绍了各种http 客户端java 实现。我正在寻找任何可以提供有关 NTLM 协议实现差异信息的链接。
在一台 Windows 机器上，我发现 commons-http 客户端 3.1 实现失败并出现授权错误（http 状态代码 401），但 java 1.5 实现成功。由于 NTLM 身份验证协议的 java 1.5 实现不是开源的，因此我无法比较这两个实现来了解可能出现的问题。
更新 1
我知道 commons http 客户端不支持 NTLM v2。这个链接提供了各种java http客户端实现之间的比较，并提到apache http客户端提供了 >部分 NTLM 协议的实现。它没有详细介绍它。
在进一步解决问题时，我还发现 此链接 提供的 NTLM 实现与 < a href="http://www.innovation.ch/" rel="nofollow">HTTPClient 在 Windows 机器上工作（公共 http 客户端实现不能像我上面提到的那样工作）。
更新2
通过嗅探数据包（使用wireshack），我意识到commons http客户端3.1 ntlm协议实现不会在类型3消息中生成NTLM响应。这是由 JDK 实现生成的。您是否知道任何服务器/客户端设置表明如果 NTLM 响应数据为空，身份验证将失败？ （因为我们面临的身份验证失败只能在一台计算机上重现。在其他地方身份验证会成功。）
This link details on the various http client java implementations. I am looking for any links which could provide information about their NTLM protocol implementation differences.
On one of the windows machine, I found that the commons-http client 3.1 implementation fails with an authorization error (http status code 401) but the java 1.5 implementation succeeds. Since the java 1.5 implementation of the NTLM authentication protocol is not open source, I cannot compare the two implementations to understand what could be going wrong.
Update 1
I am aware of the fact that commons http client does not support NTLM v2. This link provides a comparison between various java http client implementations and mentions that apache http client provides a partial implementation of NTLM protocol. It does not detail more about it.
On troubleshooting the issue further I also found that the NTLM implementation provided by this link in combination with HTTPClient works on the windows machine (the commons http client implementation does not work as I mention above).
Update 2
By sniffing packets (using wireshack) I realized that the commons http client 3.1 ntlm protocol implementation does not generate the NTLM Response in the Type 3 message. This is generated by the JDK implementation. Do you know of any server/client setting which indicates that the authentication would fail if the NTLM response data is empty? (since the authentication failure we are facing is reproducible only on one machine. The authentication succeeds else where.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Commons httpclient 3.1 不实现 NTLMv2，它仅实现较旧的 NTLM（又名 NTLMv1）规范。
Commons httpclient 3.1 does not implement NTLMv2, it only implements the older NTLM (aka NTLMv1) specification.
我们找到了这个问题的根本原因。导致身份验证错误的配置设置由名为 NoLMHashPolicy 的安全策略控制。启用此策略意味着 Windows 服务器将不再存储任何密码的 LM 哈希值，并将使用 NT 响应哈希来进行身份验证。由于来自 commons http 客户端 3.1 库的 NTLM 协议实现根本不计算 NT 响应，因此在启用此设置时可能会遇到此错误。有关此设置的更多详细信息，请访问此处。
作为一种解决方案，人们可以只添加 AuthScheme 接口的实现，并从更高版本的 commons http 客户端库（例如 4.1.2）中提取代码，该代码计算类型 3 消息中的 NT 响应。不要忘记更新 NT 响应字段的长度和偏移值。
一旦 AuthScheme 接口的实现准备就绪，就可以使用 AuthPolicy.registeryScheme() 方法进行注入。
We found the root cause of this issue. The configuration setting which lead to the authentication error was controlled by a security policy called NoLMHashPolicy. Enabling this policy means the windows server would no more store the LM Hash value for any password and it would use the NT Response hash to do the authentication. Since the NTLM protocol implementation from commons http client 3.1 library does not at all calculate the NT response one could face this error when this setting is enabled. More details about this setting can be found here.
As a solution one could just add an implementation of the AuthScheme interface and extract out the code from higher versions of the commons http client library (for e.g. 4.1.2) which computes the NT Response in the Type 3 message. Do not forget to update the length and the offset values for the NT Response fields.
Once the implementation of AuthScheme interface is ready it can be injected using the AuthPolicy.registeryScheme() method.