title: NTLM challenge fails or is not in the correct order, towards Exchange 2013
body: <p>I have an issue with NLTM authentication on Microsoft Exchange 2010. I am making an app to fetch some data from EWS Exchange and since I have NTLM enabled on the Exchange server I need to make sure that my requests follow the NTLM handshake procedure. I have researched the procedure and I understand that it is comprised out of six steps that make a 4-way handshake. The snippet below explains it clearly:</p>
  
  <pre><code>1: C  --&gt; S   GET ...
  
  2: C &lt;--  S   401 Unauthorized
                WWW-Authenticate: NTLM
  
  3: C  --&gt; S   GET ...
                Authorization: NTLM &lt;base64-encoded type-1-message&gt;
  
  4: C &lt;--  S   401 Unauthorized
                WWW-Authenticate: NTLM &lt;base64-encoded type-2-message&gt;
  
  5: C  --&gt; S   GET ...
                Authorization: NTLM &lt;base64-encoded type-3-message&gt;
  
  6: C &lt;--  S   200 Ok
  </code></pre>
  
  <p>Letter C stands for the client and letter S stands for the server. More information on NLTM can be found <a href="https://www.innovation.ch/personal/ronald/ntlm.html" rel="nofollow noreferrer">here</a>, which I also use for reference.</p>
  
  <p>So the client issues a GET request to which the server responds with a 401, telling the client that it needs to identify itself. It also sends the authentication method in the corresponding header, which in this case is NTLM. Then the client sends what is know as the Type-1 message which contains the host and domain name of the client. Then, the server responds with what is known as the Type-2 message which contains the NTLM challenge. The client then responds with another request, Type-3 Message which contains the username, domain, host name and two responses.</p>
  
  <p>I also understand that NTLM authenticates connections, not requests and I take the necessary steps to ensure that the connection is kept alive.</p>
  
  <p>Now to verify that I can send requests through NTLM towards EWS I used a tool called <a href="https://www.soapui.org/" rel="nofollow noreferrer">SoapUI</a>, to send my SOAP request. SoapUI has an in built feature to handle NTLM, so I just enter the username, password and domain there and it handles the NTLM handshake with the server upon sending the request. Now, all of this works fine through SoapUI, the requests goes through the handshake and ultimately I get a 200 response from the server. To show you this I used Microsoft Message Analyzer to inspect the incoming and outgoing http requests. These are the requests between SoapUI and the server which occurred when I sent the initial request from SoapUI.</p>
  
  <p><a href="https://i.stack.imgur.com/VA0JS.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/VA0JS.jpg" alt="SoapUI request"></a></p>
  
  <p>As you can see these requests follow the above diagram in the form in which the handshake is supposed to occur.</p>
  
  <p>Now, the turning point. I do all of this, theoretically the same, through my application. In my Node based app I use <a href="https://github.com/gautamsi/ews-javascript-api" rel="nofollow noreferrer">this</a> library to issue requests to the EWS, in turn it also uses <a href="https://github.com/SamDecrock/node-http-ntlm" rel="nofollow noreferrer">this</a> library to handle the NTLM handshake. So apart from me setting the username, password, url, domain and hostname there is nothing else I can do wrong in order to break this. So I format my request using the library and issue it only to see that it fails to authenticate via NTLM. I looked into both of these libraries and I can see that httpntlm follows the NTLM handshake protocol, and in the end sends a proper NTLM token, but I can't figure out what is wrong. Here is what the http flow looks like when I issue a request from my app.</p>
  
  <p><a href="https://i.stack.imgur.com/Qz7rh.jpg" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Qz7rh.jpg" alt="Application HTTP"></a></p>
  
  <p>Now just by looking at this, and the previous image you can spot the differences. First of all, the initial request and response that have no authentication headers are not present. I am not sure if they are optional in this NTLM handshake so the library omits them while SoapUI does not?</p>
  
  <p>Also why is the second image the Authentication header to NTLMv2 in the second image and only to NTLM in the first one. I know there are two versions of NTLM and I have them both enabled on the server, but why is it differently specified in the requests. I can't find any of the libraries specifying NTLMv2 exactly.</p>
  
  <p>In the second image it also seems that the Type-2 message might have never arrived as a response from the server?</p>
  
  <p>Anyways, I can't figure out what is going on here and why this major difference in the http flow. Any help would be appreciated.</p>