0

My situtation is very very similar to the one mentioned on Eradicating 401 "Unauthorised" responses followed by 200 "Ok" responses

But it doesn't provide an adequate response for us.

I have an example of simple GET request, when made by running the api locally without IIS results in one response which is OK/200: Fiddler trace here

But when it's hosted on IIS it returns two 401s and one 200: Fiddler trace here

Also here's the IIS network auth configuration : Config

In application that calls the API we check for 200 Response code and we receive intermittent 200/401 in the code which makes the validation really annoying, the request goes through perfectly in each case.

Any help here would be very much appreciated, if this is the way the NTLM authentication works, is there any other way to validate the call to the api was successful eventually? As in the end that's what we want to know in the caller application.

As mentioned in some articles I have tried moving NTLM to the top of the providers list (Negotiate at bottom) in IIS -> Authentication -> Providers list but that doesn't resolve this

Thanks for taking a look.

Edit: Here's the request headers in fiddler in case of IIS:

  1. Request 1 with 401 : img
  2. Request 2 with 401 : img
  3. Request 2 with 200 : img

Edit 2: Based on answer by MisterSmith and some other reading, this is the way NTLM authentication works, its more about how we handle the response in the application.

In my case I am using .net core HttpClient Library to make a request and it has a possible issue with the way it handles NTLM authentication. If anyone is interested in that it can be found here: NTLM authentication HttpClient in Core

dhruvwalter
  • 3
  • 1
  • 3
  • You need not only to collect the Fiddler trace but to analyze the actual responses (headers like Authorization) so as to see what exactly happens. Better have your domain administrators aside to assist on analyzing packets sent to DC and Kerberos logs. – Lex Li Jan 26 '21 at 19:20
  • Ofcourse i have added the request header screenshots from fiddler – dhruvwalter Jan 26 '21 at 19:29

1 Answers1

0

This is basically just how it works - the first 2 requests of the handshake the user isnt successfully authenticated yet, so a 401 is expected and totally reasonable.

If you can (somehow) get the browser to always send auth headers (just for this site!) that would remove one of the 401's, the other is unavoidable without ditching NTLM entirely.

The difference between running locally and running in IIS in your case is the authentication module which is intercepting and modifying the headers. If you were to turn off auth in IIS it will also return single 200 responses (this is a test not a solution for obvious reasons).

200/401 in the code which makes the validation really annoying

The 401, 401, 200 will all come from the same socket, in that order. If you look at the response headers on the 401's you should be able to confirm which are expected. Also IIS has a sub-status visible in the access logs and request context from code running in IIS. Pretty sure you can rewrite based on substatus conditions as well as headers - this might help differentiate requests as a last resort?

is there any other way to validate the call to the api was successful eventually

NTLM uses a keep alive socket to send multiple requests - just keep reading from the socket until a reasonable timeout and store the final response code received.

moving NTLM to the top of the providers list

Im not sure what changing the order would do, but something that jumps out at me - its common for system.webServer/security/authentication/windowsAuthentication section to be locked so changes at the web.config level will be ignored and need to be applied at the machine.config level.

MisterSmith
  • 2,884
  • 1
  • 10
  • 13