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 pla

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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.