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

【问题标题】：Avoiding 401 response for each request using NTLM使用 NTLM 避免每个请求的 401 响应
【发布时间】：2010-11-16 09:19:48
【问题描述】：

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

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

为了查看流量，我首先使用了 Fiddler 应用程序。不知何故，当我使用 Fiddler 时，会话开始时只有 1 个身份验证过程（完全如我所愿），但是当我关闭 Fiddler 并通过 WireShark 检查流量时，我可以看到每个请求我仍然有这个 401 响应.

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

有人可以建议吗？

【问题讨论】：

标签： iis iis-6 ntlm http-status-code-401

【解决方案1】：

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

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

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

【讨论】：

谢谢。关于标题，我检查了它，总是有“保持活力”。除了 AuthPersistSingleRequest（如我附加的帖子中所述）之外，还有哪些 IIS 设置可以帮助我，你知道吗？
+1 表示埃里克本人的回复。我要亲自感谢您创造了出色的 Fiddler。它让我对 HTTP 有了更好的理解，也让我和其他许多人成为了更好的 Web 开发人员 :)
我的结论：没有办法完全摆脱 NTLM 的 401（前两个除外）。当使用 POST 方法时，它们总是会回来，在使用 Web 服务时也是如此 - 创建到 IIS 的新连接，因此会发生新的身份验证过程（再产生 2 个 401）。

【解决方案2】：

唯一的方法是仅在登录页面上使用 NTLM 并使用像 here 这样的 cookie

【讨论】：

【解决方案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-distribution-points.aspx

【讨论】：

正是我想要的，消除了大部分不必要的往返。

【解决方案4】：

您在自己的域中尝试过吗？

setspn -a FQDNServerName applicationPoolServiceAccount
setspn -a biosServerName applicationPoolServiceAccount

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

【讨论】：

【解决方案5】：

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

【讨论】：

您好，感谢您的回答。我正在尝试从服务器端找到解决方案，因此我不需要更改每个客户端浏览器的设置。你能想到别的吗？
此设置确定客户端是否应随请求发送安全信息。如果请求不包含安全信息，您将收到 401 响应。
在服务器请求之前，客户端不会发送安全信息。 401 响应是服务器的询问方式。第一个 401，无论是否添加到 Intranet Zone，都无法避免。这只会使身份验证透明，而不是弹出登录对话框。此外，受信任的站点默认不会自动进行 NTLM 握手。只有 Intranet Zone 会。

【解决方案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 元数据库资源管理器来编辑这些属性？它是编辑属性的更简洁的方法，并且可能比直接编辑 XML 文件更有帮助。

避免该问题的一种方法是在 HTTP 响应中插入 Cache-Control 标头，用于在任何页面上不会频繁更改的资源。就我而言，我缓存了 css（尽可能使用外部 css 来优化）、js 和 img 文件。由于我在我们的主页上加载了大约 60 个此类文件，因此我们能够立即消除大约 120 401 个错误！

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

【讨论】：

观察两个 HTTP 401 响应对于 NTLM 身份验证是正常的，因为这是协议握手的一部分（第一个 401 是由于初始匿名请求，第二个 401 是由于 NTLM 质询）而Kerberos 身份验证只会响应一个 HTTP 401。有关详细信息，请参阅本文：blogs.technet.microsoft.com/mist/2018/02/14/…

【解决方案7】：

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

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

【讨论】：