针对Exchange 2013的NTLM挑战失败或顺序不正确

Question

我在Microsoft Exchange 2010上遇到NLTM身份验证问题。我正在制作一个应用程序从EWS Exchange获取一些数据，因为我在Exchange服务器上启用了NTLM，我需要确保我的请求遵循NTLM握手程序。我已经研究了这个程序，我知道它是由六个步骤组成的，可以进行四次握手。下面的代码清楚地解释了它：

1: C  --> S   GET ...

2: C <--  S   401 Unauthorized
              WWW-Authenticate: NTLM

3: C  --> S   GET ...
              Authorization: NTLM <base64-encoded type-1-message>

4: C <--  S   401 Unauthorized
              WWW-Authenticate: NTLM <base64-encoded type-2-message>

5: C  --> S   GET ...
              Authorization: NTLM <base64-encoded type-3-message>

6: C <--  S   200 Ok

字母C代表客户端，字母S代表服务器。有关NLTM的更多信息可以在here找到，我也将其用作参考。

因此客户端发出一个GET请求，服务器用401响应，告诉客户端它需要识别自己。它还在相应的头中发送身份验证方法，在本例中为NTLM。然后，客户端发送所谓的Type-1消息，其中包含客户端的主机和域名。然后，服务器使用所谓的包含NTLM质询的Type-2消息进行响应。然后客户端响应另一个请求，Type-3 Message，其中包含用户名，域名，主机名和两个响应。

我也理解NTLM验证连接，而不是请求，我采取必要的步骤来确保连接保持活动。

现在要验证我是否可以通过NTLM向EWS发送请求，我使用了一个名为SoapUI的工具来发送我的SOAP请求。 SoapUI有一个内置的功能来处理NTLM，所以我只需在那里输入用户名，密码和域，它在发送请求时处理与服务器的NTLM握手。现在，所有这一切都可以通过SoapUI工作，请求通过握手，最终我从服务器得到200响应。为了向您展示这一点，我使用Microsoft Message Analyzer来检查传入和传出的http请求。这些是我从SoapUI发送初始请求时发生的SoapUI和服务器之间的请求。

正如您所看到的，这些请求按照上图所示的方式进行握手。

现在，转折点。通过我的应用程序，我在理论上完成了所有这一切。在我的基于节点的应用程序中，我使用this库向EWS发出请求，反过来它也使用this库来处理NTLM握手。因此，除了我设置用户名，密码，网址，域名和主机名之外，没有别的办法可以解决这个问题。因此，我使用库格式化我的请求并仅发出它以查看它无法通过NTLM进行身份验证。我查看了这两个库，我可以看到httpntlm遵循NTLM握手协议，最后发送了一个合适的NTLM令牌，但我无法弄清楚出了什么问题。以下是我从应用程序发出请求时http流的样子。

现在只需看一下这个，就可以看到上一张图片。首先，不存在没有认证头的初始请求和响应。我不确定它们在这个NTLM握手中是否是可选的，所以库省略了它们而SoapUI没有？

另外，为什么第二个图像是第二个图像中的NTLMv2的认证头，而第一个图像中只是NTLM。我知道有两个版本的NTLM，我在服务器上都启用了它们，但为什么在请求中指定了不同的版本。我无法找到任何完全指定NTLMv2的库。

在第二张图片中，似乎Type-2消息可能从未作为来自服务器的响应而到达？

无论如何，我无法弄清楚这里发生了什么以及为什么这个主要的差异在于http流。任何帮助将不胜感激。

Answer 1

NTLMv2对ews-javascript-api@next的支持已更新。请参阅ews-javascript-api-auth@1.2.0模块。您可以在github页面上安装1.2.0并使用示例。

@next是ews-javascript-api的dev build标签，它很快就会出现在dev版本中（跟踪github上的里程碑0.9）。

在guthub中解决这个问题，以便更快地解决问题。