You'll have to figure out how you'll reply to the Type 2 message's challenge, where the user's password is MD4 hashed and used to create DES keys to encrypt the challenge data. The client responds to the Type 2 message by resubmitting the request with an Authorization header containing a Base-64 encoded Type 3 message: GET /index.html HTTP/1.1Īuthorization: NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0+d8ViWpjBw圆BhHRmspst9GgPOZWPuMITqcxg=įinally, the server validates the responses in the client's Type 3 message and allows access to the resource. WWW-Authenticate: NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA= The server replies with a 401 status containing a Type 2 message in the HTTP/1.1 401 Unauthorized The relevant request headers appear as follows: GET /index.html HTTP/1.1Īuthorization: NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg= This implies that the server and client must support persistent connections, via either the HTTP 1.0-style "Keep-Alive" header or HTTP 1.1 (in which persistent connections are employed by default). From this point forward, the connection is kept open closing the connection requires reauthentication of subsequent requests. The Type 1 message is Base-64 encoded for transmission. The client resubmits the request with an Authorization header containing a Type 1 message parameter. Note that Internet Explorer will only select NTLM if it is the first mechanism offered this is at odds with RFC 2616, which states that the client must select the strongest supported authentication scheme. NTLM is presented as a supported authentication mechanism via the 401 Unauthorized The server responds with a 401 status, indicating that the client must authenticate.
The client requests a protected resource from the server: GET /index.html HTTP/1.1 Quoting from this document about the NTLM authentication protocol: When you receive a HTTP 401 from IIS with a WWW-Authenticate header containing NTLM, you now have the fun of implementing the NTLM authentication protocol. "Windows integrated authentication" is what's known as NTLM authentication. Obviously this uses Kerberos rather than NTLM/Negotiate, so this may or may not work depending on your exact situation. There are several client implementations such as http-ntlm, but they are not truly integrated since they require the user password - they do not use SSPI to do transparent auth.Ģ019 Update: It appears to be possible to use the kerberos library to do true Windows-integrated HTTP auth using SSPI (ie, use the node process' token to do transparent auth). node-sspi uses SSPI (the Windows security API) to handle the server side of things, but does not do client auth. 2015 Update: There are now some modules that implement Windows-integrated authentication.