1

When performing a curl with --ntlm, what is happening between the WWW-Authenticate header being sent back, and then then the second NTLM Authorization header being sent to finally return a 200?

Authorization: NTLM xxxxxxxx

< HTTP/1.1 401 Unauthorized < WWW-Authenticate: NTLM xxxxxxxx

Authorization: NTLM xxxxxxxxxx

< HTTP/1.1 200 OK

I want to be able to take the first NTLM header (this stays constant with the username/password I believe), and build it into a script, take the returned header, and send the second NTLM one back to authenticate. What I don't understand is how the challenge (WWW-Authenticate header?) is taken in, and then sent back as another NTLM header.

I have tried using the WWW-Auth header as the second NTLM-Auth header, I didnt expect it to work but tried.

notreallyanengineer
  • 11
  • 2

2 Answers2

4

NTLM authentication is a multi-step process, which is achieved over HTTP as follows:

  1. Client makes an HTTP request (no authentication data provided).
  2. Server responds with a 401 Unauthorized, and advertises that it supports NTLM authentication via the WWW-Authenticate: NTLM header.
  3. The client generates its first authentication token using InitializeSecurityContext and sends it to the server in the Authorization: NTLM <base64 encoded client token #1> header.
  4. The server takes the client's token and passes it to AcceptSecurityContext, which generates the server's token. The server again responds with 401 Unauthorized, but this time includes its token in the WWW-Authenticate: NTLM <base64 encoded server token> header.
  5. The client takes the server's token, and passes it to InitializeSecurityContext to generate its second token that it sends back to the server in the Authorization: NTLM <base64 encoded client token #2> header.
  6. The server takes the client's second token and passes it to AcceptSecurityContext, which (assuming the authentication is successful) completes the process, and the server returns the normal 200 OK response.

Both InitializeSecurityContext and AcceptSecurityContext return some additional data on the initial call that must be included in the subsequent calls, making the authentication process stateful, so all of the above steps must occur over the same connection to the server.

Iridium
  • 23,323
  • 6
  • 52
  • 74
0

NTLM is actually a three-request handshake, where the client doesn't send any credentials the first time a resource is requested. This means that the first request is anonymous, even though credentials have been configured for the resource. When Windows authentication is enabled and anonymous authentication is disabled, this anonymous request results in an HTTP 401 status.

The second request will be an NTLM challenge, in which the client resends the original request with an additional "Authorization" header containing NTLM (Type-1 message). The server then sends an NTLM challenge (Type-2 message) back to the client with an HTTP 401 status.

The third request will be the original request that the client sends again by adding a challenge-response (NTLM Type-3 message) to the Authorization header. The server then authenticates the user and returns a response with an HTTP 200 status if successful.

YurongDai
  • 1,362
  • 1
  • 2
  • 7
  • Ok, so another question --when I do a curl -u and input the username and password, It will complete the 3 way handshake successfully. I don't want to use username/password in my curl. When I try to initiate using the NTLM header (which is normally generated from the credentials and sent), curl stops and does not complete the 3 way handshake. Is there a way to do complete the 3 way handshake, with the first send using the NTLM Auth header? – notreallyanengineer Nov 04 '22 at 12:51
  • I don't think this is possible, the NTLM protocol requires the client to be authenticated by providing a username and corresponding password. This allows an exchange to be established between the user's device and the server. After identifying the user's login credentials, the server can check access rights and allow the user in. This is an implementation specific process, which should be executed according to the actual three-way handshake process. – YurongDai Nov 10 '22 at 06:22