Avoiding 401 response for each request using NTLM

Question

We have here an asp.net 3.5 application using NTLM based windows authentication. The system runs on a private network that actually distributed over different geographic places (connected via VPN).

We are now trying to optimize the website's performance. Because the way NTLM works, every new request to the IIS is composed with 3 different requests while the first 2 is 401 responses. We are trying to minimize the amount of these requests to be only at the beginning of the session. We found this solution. Unfortunately it didn't change anything and we keep getting this 401 response (which consumes time).

In order to see the traffic i first used the Fiddler app. Somehow, when I use Fiddler, there is only 1 authentication process at the beginning of the session (exactly as I wish), but when I close Fiddler and check the traffic via WireShark I can see that I still have this 401 response for each request.

The used clients are IE6, IIS version 6.

Can someone advise?

Angelicaangelico

Answer 1

NTLM/Negotiate, unlike all other HTTP authentication schemes, are connection-oriented protocols.

In IIS, there are various settings which control whether authentication will be demanded for all requests on a previously authenticated connection (e.g. AuthPersistSingleRequest). Independent of that setting, I believe IIS will automatically demand re-authentication when making a POST request.

If your server is impairing connection reuse (e.g. by sending a Connection: close header in responses) you must fix that because otherwise the reauthentication will occur. You can easily check for such authentication-reuse foiling headers using Fiddler.

Trahan

Thanks. About the header, I checked it and there is always "keep alive". What IIS settings other than AuthPersistSingleRequest (as described in the post I attached) that can help me do you know? – Angelicaangelico

+1 for response from Eric himself. I want to thank you personally for creating the fantastic Fiddler. It has made my understanding of HTTP much better and made me and many others better web developers :) – Liquescent

My conclusion: no way to totally get rid of the 401s with NTLM (except from the first two). They will always come back when using POST method, also when using web services - a new connection to the IIS is created, there for, a new authentication process is occur (yield 2 more 401s). – Angelicaangelico

Answer 2

The only way is to use NTLM on login page only and use cookie like here

Vonnievonny

Answer 3

On a related topic; if you are using IIS7.0 and kerberos authentication it appears AuthPersistNonNTLM=true can be used to avoid 401 round-trips for each request.

http://msdn.microsoft.com/en-us/library/aa347548(VS.90).aspx

http://blogs.technet.com/b/configurationmgr/archive/2010/06/03/solution-you-may-experience-slow-performance-when-using-bits-and-kerberos-authentication-on-configmgr-2007-distribution-points.aspx

Outer

Exactly what I was looking for, eliminates most of the unnecessary round-trips. – Benne

Answer 4

Have you tried this in your domain?

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

It allows the application pool to service NTLM auth requests.

Neology

Answer 5

It might be your security settings on IE6 for the site. Try changing to local intranett or trusted site.

Hammon

Hi, thanks for your answer. i;m tring to find a solution from the server side so i won't need to change setting for each clients' browser. can you think of something else? – Angelicaangelico

This setting determines wether the client should send security info with the request. If the request does not contain the security info you will get a 401 response. – Hammon

Client doesn't send security info until the server asks for it. 401 response is how the server asks. You can't avoid the first 401, whether you add it to the Intranet Zone or not. That will just make the auth transparent, instead of a popup login dialog. Also, Trusted Sites will not do automatic NTLM handshake by default. Only Intranet Zone will. – Recce

Answer 6

I have the exact same problem! I am using the same environment as you. Except that I see 2 401's even in Fiddler. I had spent a couple of days on that problem and then just gave up on it. AuthPersistence did not work for me either. But here are the links that I had found, maybe they will work in your case.

http://msdn.microsoft.com/en-us/library/ms525244.aspx

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/b0b4ec5c-74f8-43e9-ac64-d8b852568341.mspx?mfr=true

http://technet.microsoft.com/en-us/library/cc786094.aspx

http://technet.microsoft.com/en-us/library/cc781339(WS.10).aspx

I tried to set the flag at both the virtual directory and website level, but it didn't help. Are you using the IIS Metabase Explorer to edit those properties? Its the cleaner way to edit properties and may help more than directly editing the XML file.

One way to circumvent the problem is to insert the Cache-Control Header in the HTTP response for the resources that are not going to change frequently on any page. In my case, I cached the css (use external css as much as possible to optimize this), js and img files. Since I have about 60 files of these types that get loaded on our homepage, we were able to eliminate about 120 401 errors straight away!

Make sure you use the Cache-Control header and not the if-modified or e-tag based caching where a 401 and a 304 will still be generated even when the files are cached.

Liquescent

Observing two HTTP 401 responses is normal for NTLM authentication as that is part of the protocol's handshake (the first 401 is due to the initial anonymous request, and the second 401 is due to the NTLM challenge) whereas Kerberos authentication will only respond with one HTTP 401. See this article for more info: blogs.technet.microsoft.com/mist/2018/02/14/… – Rare

Answer 7

I was having this problem as well except that, for me, it was mostly JS and CSS files which caused this. My site (like most sites) keeps JS and CSS files in there own directories. So the solution for me was to simply go to those directories in IIS and enable Anon Auth (I say simply but it took over two years for me to work this out; thanks to this post). Now the site still requires Windows auth but the sub directories for JS and CSS files do not. IOW, it seems to be working perfectly.

I also would never put sensitive information in a JS file (or CSS file for that matter) and would suggest that you do not either. If you do, you will obviously want to move the sensitive information in these files out of these directories.

Bernhardt