2015更新： 现在有些模块实现了Windows集成的身份验证。 node-
sspi使用SSPI（Windows安全API）来处理服务器端的事务，但不执行client
auth。有几种客户端实现，例如http-
ntlm，但是由于需要用户密码，因此它们并未真正集成-
它们不使用SSPI进行透明身份验证。

2019更新： 似乎可以使用kerberos库通过SSPI进行真正的Windows集成的HTTP身份验证（即，使用节点进程的令牌进行透明身份验证）。请参阅kerberos-
agent。显然，这使用的是Kerberos，而不是NTLM
/ Negotiate，因此，根据您的实际情况，此方法可能有效也可能无效。

“ Windows集成身份验证”是所谓的NTLM身份验证。现在，当您从IIS收到带有WWW-Authenticate包含的标头的HTTP
401时NTLM，您将很有趣地实现NTLM身份验证协议。引用本文档中有关NTLM身份验证协议的内容：

1. 客户端从服务器请求受保护的资源：

   GET /index.html HTTP/1.1
   

2. 服务器以401状态响应，指示客户端必须进行身份验证。NTLM通过WWW-Authenticate标头作为受支持的身份验证机制提供。通常，服务器此时会关闭连接：

   HTTP/1.1 401 Unauthorized
   

   WWW-Authenticate: NTLM
   Connection: close

请注意，如果Internet Explorer是第一个提供的机制，它将仅选择NTLM。这与RFC 2616不一致，RFC
2616指出客户端必须选择支持最强的身份验证方案。

1. 客户端使用Authorization包含Type 1消息参数的标头重新提交请求。Type 1消息经过Base-64编码以进行传输。从这一点开始，连接保持打开状态。关闭连接需要重新验证后续请求。这意味着服务器和客户端必须通过HTTP 1.0样式的“ Keep-Alive”标头或HTTP 1.1（默认情况下采用持久连接）来支持持久连接。相关的请求标头显示如下：

   GET /index.html HTTP/1.1
   

   Authorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg==

2. 与该服务器的应答401包含状态类型2消息的WWW-Authenticate标题（再次，BASE-64编码）。如下所示。

   HTTP/1.1 401 Unauthorized
   

   WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA=

3. 客户端通过用Authorization包含Base-64编码的Type 3消息的标头重新提交请求来响应Type 2 消息：

   GET /index.html HTTP/1.1
   

   Authorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjBwx6BhHRmspst9GgPOZWPuMITqcxg==

4. 最后，服务器验证客户端的Type 3消息中的响应，并允许访问资源。

    HTTP/1.1 200 OK
   

您将必须弄清楚如何回复Type
2消息的Challenge，其中用户密码是MD4哈希值，并用于创建DES密钥来加密挑战数据。

我不确定如何访问已登录用户的凭据数据，尽管我确定这将涉及编写本机C
++插件，以便您与必要的Windows
API进行通讯，但是我不确定将如何完成此操作。或者，我想您可以只要求输入用户密码。

或者，您可以通过为您处理NTLM混乱的软件来代理您的Node请求。