如何通过反向代理启用 Windows 身份验证？

Posted 2023-02-15

【中文标题】如何通过反向代理启用 Windows 身份验证？

【英文标题】：How to enable windows authentication through a reverse proxy?

【发布时间】：2011-05-21 02:05:18

【问题描述】：

对不起，如果它是重复的，因为我不是安全或网络专家，我可能错过了正确的术语来查找信息。

我正在开发一个应用程序来拦截和修改 Web 浏览器和 Web 服务器之间的 HTTP 请求和响应（有关背景，请参阅 how to intercept and modify HTTP responses on server side?）。我决定在 ASP.Net 中实现一个反向代理，它将客户端请求转发到后端 HTTP 服务器，将响应中的链接和标头转换为正确“代理”的 URL，并在提取相关信息后将响应发送给客户端从响应。

一切正常，除了身份验证部分：Web服务器默认使用NTLM身份验证，仅通过反向代理转发请求和响应不允许用户进行身份验证远程应用程序。反向代理和 Web 应用程序都在同一台物理机器上，并在同一台 IIS 服务器中执行（Windows 服务器 2008/IIS 7，如果这很重要）。我尝试在反向代理应用程序上启用和禁用身份验证，但没有成功。

我找了相关资料，好像和“双跳问题”有关，不明白。我的问题是：有没有办法通过反向代理使用 NTLM 对远程应用程序上的用户进行身份验证？如果没有，我可以使用其他身份验证方法吗？

即使您对我的问题没有解决方案，只要向我指出相关信息以帮助我摆脱困惑，这将是很棒的！

【参考方案1】：

我发现了问题所在（并且是 NTLM）：为了让浏览器向用户询问其凭据，响应必须具有 401 状态代码。我的反向代理将响应转发到浏览器，因此 IIS 添加了标准 html 代码来解释无法访问请求的页面，从而阻止浏览器询问凭据。 当状态码为 401 时，通过删除响应内容解决了问题。

尽管我对几年前回答这个问题的人表示应有的尊重，但我必须承认这显然是错误的。当状态码为 401 时，问题在删除响应内容后确实解决了，但它与最初的问题无关。 事实是，Windows 身份验证是为了通过本地 Windows 网络对人员进行身份验证，其中没有代理服务器，甚至不需要代理服务器。 NTLM 身份验证的主要问题是该协议不对 HTTP 会话进行身份验证，而是对底层 TCP 连接进行身份验证，据我所知，没有办法从 asp 代码中访问它。 我尝试过的每台代理服务器都破坏了 NTLM 身份验证。 Windows 身份验证对用户来说很舒服，因为他永远不需要输入您的密码来访问您的 Intranet 中可能存在的任何应用程序，这对安全人员来说很可怕，因为如果站点域受信任，则自动登录甚至没有提示IE，让网络管理员感到震惊，因为它将应用程序、传输和网络层融合为一些“Windows 的杯子”，而不仅仅是简单的 http 流量。

【参考方案2】：

如果 TCP 数据包没有完全按照反向代理收到的转发 > 它们，NTLM 将不起作用。这就是为什么许多反向代理不适用于 NTLM 身份验证的原因。 （如 nginx）> 他们正确转发 HTTP 请求，但不转发 TCP 数据包。

Nginx 具有使用 NTLM 身份验证的功能。需要启用只能通过 http_upstream_module 使用的 Keepalive。此外，在 location 块中，您需要指定您将使用 HTTP/1.1，并且应为每个代理请求清除“Connection”标头字段。 Nginx 配置应该类似于：

upstream http_backend 
    server 1.1.1.1:80;

    keepalive 16;


server 
...

location / 
       proxy_pass http://http_backend/;
       proxy_http_version 1.1;
       proxy_set_header Connection "";
    ...
    
 

我为这个问题挠了很久，但上面的方法对我有用。请注意，如果您需要代理 HTTPS 流量，则认为需要单独的上游块。再澄清一点，“keepalive 16;”指定您的代理允许保持的与上游的同时连接数。根据网站上的预期同时访问者数量调整数量。

【讨论】：

谢谢，这行得通。我还添加了 proxy_set_header Host、X-Real-IP、X-Forwarded-For；到“位置/”标签。

小心这种方法，首先阅读mailman.nginx.org/pipermail/nginx/2016-February/049889.html。用户会话可能会混合在一起，因此用户可能会意外进入另一个用户的会话。

【参考方案3】：

虽然这是一篇旧文章，但我只想报告它对我来说非常适合 Apache2.2 反向代理和 keepalive=on 选项。显然，这使代理和 SharePoint 主机之间的连接保持打开并“固定”到客户端代理连接。我不完全了解这背后的机制，但它运作良好。

但是：有时，我的用户会遇到以其他用户身份登录的问题。因此，会议似乎有些混淆。我将不得不对此进行进一步的测试。

所有问题的解决方案（如果您拥有有效的签名 SSL 证书）：将 IIS 切换到基本身份验证。这工作得很好，甚至 Windows（即带有 SharePoint 连接的 Office、所有基于 WebClient 的进程等）也不会抱怨。 但是，当您只使用没有 SSL/TLS 的 http 以及自签名证书时，它们会这样做。

【参考方案4】：

我确认它适用于 apache2.2 上的“keep-alive=on”

我用 Wireshark 检查了框架，我知道为什么它不起作用。如果 TCP 数据包没有完全按照反向代理收到它们的方式转发，NTLM 将不起作用。这就是为什么许多反向代理（如 nginx）不能使用 NTLM 身份验证的原因。反向代理正确转发 HTTP 请求，但不转发 TCP 数据包。

NTLM 需要 TCP 反向代理。