我们这里有一个使用基于NTLM的Windows身份验证的asp.net 3.5应用程序。 该系统在专用网络上运行，该网络实际上分布在不同的地理位置（通过VPN连接）。
我们现在正在尝试优化网站的效果。由于NTLM的工作方式，每个对IIS的新请求由3个不同的请求组成，而前2个是401个响应。我们正在尝试将这些请求的数量最小化，仅在会话开始时。我们找到了this解决方案。不幸的是，它没有改变任何东西，我们继续得到这个401响应（消耗时间）。
为了看到我第一次使用Fiddler应用程序的流量。不知何故，当我使用Fiddler时，会话开始时只有一个身份验证过程（完全按照我的意愿），但当我关闭Fiddler并通过WireShark检查流量时，我可以看到每个请求仍然有401响应
使用过的客户端是IE6，IIS版本6。
有人可以提供建议吗？
答案 0 :(得分：19)
与所有其他HTTP身份验证方案不同，NTLM / Negotiate是面向连接的协议。
在IIS中，有各种设置可控制是否要求对先前经过身份验证的连接（例如AuthPersistSingleRequest）上的所有请求进行身份验证。独立于该设置，我相信IIS会在发出POST请求时自动要求重新验证。
如果您的服务器损害了连接重用（例如，通过在响应中发送Connection：close标头），您必须修复它，否则将发生重新认证。您可以使用Fiddler轻松检查此类身份验证 - 重用欺骗标题。
答案 1 :(得分：4)
唯一的方法是仅在登录页面上使用NTLM并使用here
之类的cookie答案 2 :(得分：3)
关于相关主题;如果您使用的是IIS7.0和kerberos身份验证，则可以使用AuthPersistNonNTLM = true来避免每次请求的401次往返。
http://msdn.microsoft.com/en-us/library/aa347548(VS.90).aspx
答案 3 :(得分：3)
您是否在自己的域中尝试过此操作？
setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount
它允许应用程序池为NTLM身份验证请求提供服务。
答案 4 :(得分：2)
这可能是您网站上IE6的安全设置。尝试更改为本地Intranett或可信站点。
答案 5 :(得分：1)
我有完全相同的问题！我和你一样使用相同的环境。除了我在Fiddler看到2 401的。我花了几天时间解决这个问题然后就放弃了。 AuthPersistence对我也不起作用。但是这里有我找到的链接，也许它们会适用于您的情况。
http://msdn.microsoft.com/en-us/library/ms525244.aspx
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.
答案 6 :(得分：0)
我也有这个问题，除了对我来说，主要是JS和CSS文件导致了这个问题。我的网站（像大多数网站一样）将JS和CSS文件保存在自己的目录中。因此，我的解决方案是简单地转到IIS中的那些目录并启用Anon Auth（我简单地说，但是我花了两年时间来解决这个问题;感谢这篇文章）。现在该网站仍然需要Windows身份验证，但JS和CSS文件的子目录不需要。 IOW，它似乎完美无缺。
我也绝不会将敏感信息放在JS文件（或CSS文件）中，并建议你也不要。如果这样做，您显然希望将这些文件中的敏感信息移出这些目录。