使用 NTLM 避免每个请求出现 401 响应
我们这里有一个使用基于 NTLM 的 Windows 身份验证的 asp.net 3.5 应用程序。 该系统运行在实际上分布在不同地理位置的专用网络上（通过 VPN 连接）。
我们现在正在努力优化网站的性能。 由于 NTLM 的工作方式，对 IIS 的每个新请求都由 3 个不同的请求组成，而前 2 个是 401 响应。 我们正在努力最大程度地减少这些请求的数量，仅在会话开始时发出。 我们找到了这个解决方案。 不幸的是，它没有改变任何东西，我们不断收到这个 401 响应（这会消耗时间）。
为了查看流量，我首先使用了 Fiddler 应用程序。 不知何故，当我使用 Fiddler 时，会话开始时只有 1 个身份验证过程（完全如我所愿），但是当我关闭 Fiddler 并通过 WireShark 检查流量时，我可以看到每个请求仍然有这个 401 响应。
使用的客户端是IE6，IIS版本6。
有人可以建议吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
与所有其他 HTTP 身份验证方案不同，NTLM/Negotiate 是面向连接的协议。
在 IIS 中，有多种设置可以控制是否要求对先前经过身份验证的连接上的所有请求进行身份验证（例如 AuthPersistSingleRequest）。 与该设置无关，我相信 IIS 在发出 POST 请求时会自动要求重新身份验证。
如果您的服务器正在损害连接重用（例如，通过在响应中发送 Connection: close 标头），您必须修复该问题，否则将发生重新身份验证。 您可以使用 Fiddler 轻松检查此类身份验证重用挫败标头。
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.
您在您的域中尝试过此操作吗？
它允许应用程序池为 NTLM 身份验证请求提供服务。
Have you tried this in your domain?
It allows the application pool to service NTLM auth requests.
关于相关主题； 如果您使用 IIS7.0 和 kerberos 身份验证，则可以使用 AuthPersistNonNTLM=true 来避免每个请求的 401 往返。
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
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
唯一的方法是仅在登录页面上使用 NTLM 并使用 cookie，如此处
The only way is to use NTLM on login page only and use cookie like here
这可能是您在 IE6 上对该网站的安全设置。 尝试更改为本地 Intranet 或受信任的站点。
It might be your security settings on IE6 for the site. Try changing to local intranett or trusted site.
我有完全一样的问题！ 我用的环境和你一样。 除了我什至在 Fiddler 中也看到了 2 401。 我在这个问题上花了几天时间，然后就放弃了。 AuthPersistence 对我来说也不起作用。 但这里是我找到的链接，也许它们适用于您的情况。
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
我尝试在两个位置设置标志虚拟目录和网站级别，但没有帮助。 您是否使用 IIS Metabase Explorer 来编辑这些属性？ 它是编辑属性的更简洁的方法，并且可能比直接编辑 XML 文件更有帮助。
规避该问题的一种方法是在 HTTP 响应中插入 Cache-Control 标头，以获取任何页面上不会频繁更改的资源。 就我而言，我缓存了 css（尽可能使用外部 css 来优化）、js 和 img 文件。 由于我们的主页上加载了大约 60 个此类类型的文件，因此我们能够立即消除大约 120 401 个错误！
确保使用 Cache-Control 标头，而不是基于 if-modified 或 e-tag 的缓存，即使文件被缓存，仍会生成 401 和 304。
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.
我也遇到了这个问题，但对我来说，主要是 JS 和 CSS 文件导致了这个问题。 我的网站（像大多数网站一样）将 JS 和 CSS 文件保存在自己的目录中。 因此，我的解决方案是简单地转到 IIS 中的这些目录并启用 Anon Auth（我说的是简单的，但我花了两年多的时间才解决这个问题；感谢这篇文章）。 现在该网站仍然需要 Windows 身份验证，但 JS 和 CSS 文件的子目录不需要。 IOW，它似乎工作得很好。
我也永远不会将敏感信息放入 JS 文件（或 CSS 文件）中，并且建议您也不要这样做。 如果这样做，您显然希望将这些文件中的敏感信息移出这些目录。
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.