使用NTLM避免每个请求的401响应

Question

我们这里有一个使用基于NTLM的Windows身份验证的asp.net 3.5应用程序。 该系统在专用网络上运行，该网络实际上分布在不同的地理位置（通过VPN连接）。

我们现在正在尝试优化网站的性能。 由于NTLM的工作方式，每个对IIS的新请求由3个不同的请求组成，而前2个是401个响应。 我们正在尝试将这些请求的数量最小化，仅在会话开始时。 我们找到了解决方案。 不幸的是它并没有改变任何东西，我们继续得到这个401响应（消耗时间）。

为了看到我第一次使用Fiddler应用程序的流量。 不知何故，当我使用Fiddler时，在会话开始时只有一个身份验证过程（完全按照我的意愿），但当我关闭Fiddler并通过WireShark检查流量时，我可以看到每个请求仍然有401响应。

使用的客户端是IE6，IIS版本6。

有人可以提供建议吗？

Answer 1

与所有其他HTTP身份验证方案不同，NTLM / Negotiate是面向连接的协议。

在IIS中，有各种设置控制是否要求对先前经过身份验证的连接（例如AuthPersistSingleRequest）上的所有请求进行身份验证。 独立于该设置，我相信IIS会在发出POST请求时自动要求重新验证。

如果您的服务器损害连接重用（例如，通过在响应中发送Connection：close标头），则必须修复该问题，否则将发生重新认证。 您可以使用Fiddler轻松检查此类身份验证 - 重用欺骗标头。

Answer 2

唯一的方法是只在登录页面上使用NTLM并使用像这里的 cookie

Answer 3

关于相关主题; 如果您使用的是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年，分布points.aspx

Answer 4

你在你的域名中试过这个吗？

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

它允许应用程序池为NTLM身份验证请求提供服务。

Answer 5

它可能是您网站上IE6的安全设置。 尝试更改为本地Intranett或受信任的站点。

Answer 6

我有完全一样的问题！ 我和你一样使用相同的环境。 除了我在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 Header，以便在任何页面上不会频繁更改资源。 在我的情况下，我缓存了css（尽可能使用外部css来优化它），js和img文件。 由于我有大约60个这些类型的文件加载到我们的主页上，我们能够立即消除大约120个401错误！

确保使用Cache-Control标头而不是if-modified或基于e-tag的缓存，即使文件被缓存，仍然会生成401和304。

Answer 7

我也遇到了这个问题，除了对我来说，主要是JS和CSS文件引起了这个问题。 我的网站（像大多数网站一样）将JS和CSS文件保存在自己的目录中。 因此，我的解决方案是简单地转到IIS中的那些目录并启用Anon Auth（我简单地说，但是我花了两年时间来解决这个问题;感谢这篇文章）。 现在该网站仍然需要Windows身份验证，但JS和CSS文件的子目录不需要。 好像，它似乎工作得很好。

我也绝不会将敏感信息放在JS文件（或CSS文件）中，并建议你也不要。 如果这样做，您显然希望将这些文件中的敏感信息移出这些目录。