Avoiding 401 response for each request using NTLM

问题:

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?

回答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.

回答2:

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

回答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

回答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.

回答5:

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

回答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.

回答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.