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

发布于 2024-10-06 18:07:06 字数 696 浏览 6 评论 0原文

抱歉,如果它是重复的,因为我不是安全专家,也不是网络专家,我可能错过了查找信息的正确术语。

我正在开发一个应用程序来拦截和修改 Web 浏览器和 Web 服务器之间的 HTTP 请求和响应(请参阅 如何在服务器端拦截并修改HTTP响应?为后台)。我决定在 ASP.Net 中实现反向代理,它将客户端请求转发到后端 HTTP 服务器,将响应中的链接和标头转换为正确的“代理”URL,并在提取相关信息后将响应发送到客户端从响应中。

除了身份验证部分之外,它按预期工作:Web 服务器默认使用 NTLM 身份验证,仅通过反向代理转发请求和响应不允许用户在远程应用程序上进行身份验证。反向代理和 Web 应用程序位于同一台物理计算机上,并在同一 IIS 服务器(Windows Server 2008/IIS 7,如果有的话)中执行。我尝试在反向代理应用程序上启用和禁用身份验证,但没有成功。

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

即使您没有解决我的问题的方法,只要向我指出相关信息来帮助我摆脱困惑,那就太好了!

Sorry if it is a duplicate, as I am not a security nor network expert I may have missed the correct lingo to find information.

I am working on an application to intercept and modify HTTP requests and responses between a web browser and a web server (see how to intercept and modify HTTP responses on server side? for the background). I decided to implement a reverse proxy in ASP.Net which forwards client requests to the back-end HTTP server, translates links and headers from the response to the properly "proxified" URL, and sends the response to the client after having extracted relevant information from the response.

It is working as expected, except for the authentication part: the web server uses NTLM authentication by default, and just forwarding requests and responses through the reverse proxy does not allow the user to be authenticated on the remote application. Both the reverse proxy and the web application are on the same physical machine and are executed in the same IIS server (Windows server 2008/IIS 7 if that matters). I tried both enabling and disabling authentication on the reverse proxy app with no luck.

I have looked for information about it, and it seems to be related to the "double-hop problem", which I do not understand. My question is: is there a way to authenticate the user on the remote application through the reverse proxy using NTLM? If there is none, are there alternative authentication methods I could use?

Even if you don't have a solution to my problem, just pointing me to relevant information about it to help me get out of the confusion would be great!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

允世 2024-10-13 18:07:06

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

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

I found what the problem was (and it is NTLM): in order to have the browser asks the user for its credentials, the response must have a 401 status code. My reverse proxy was forwarding the response to the browser, so IIS was adding a standard HTML code to explain the requested page cannot be accessed thus preventing the browser from asking credentials.
The problem was solved by removing the response content when the status code is a 401.

With all due respect I have for the one that answered that some years ago, I must admit this is plainly false. The problem was indeed solved AFTER removing the response content when the status code is a 401, but it had none to do with the initial problem..
The truth is that windows authentication was made to authenticate people over local windows networks, where no proxy server is present or even needed.
The main problem with NTLM authentication is that this protocol does not authenticate the HTTP session but the underlying TCP connection, and as far as I know there is no way to access it from asp code.
Every proxy server I tried broke NTLM authentication.
Windows authentication is comfortable for an user because he won't ever need to enter your password to whatever application may lie in your intranet, frightening for a security guy because there is an auto-login without even a prompt if the site domain is trusted by IE, shocking for a network administrator because it melts the application, transport and network layer into some "windows ball of mug" instead of just plain http traffic.

回忆躺在深渊里 2024-10-13 18:07:06

如果 TCP 数据包未完全按照反向代理收到的方式转发,NTLM 将无法工作 >他们。这就是许多反向代理不支持 NTLM 身份验证的原因。 (如 nginx)>它们正确转发 HTTP 请求,但不转发 TCP 数据包。

Nginx 具有与 NTLM 身份验证配合使用的功能。需要启用 Keepalive,该功能只能通过 http_upstream_module 来使用。此外,在位置块中,您需要指定您将使用 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;”指定您的代理允许保留的与上游的同时连接数。根据网站上预计的同时访问者数量调整数量。

NTLM won't work if the TCP packets are not forwarded exactly as the reverse proxy received > them. And that's why many reverse proxy doesn't work with NTLM authentication. (like nginx) > They forward HTTP requests correcty but not the TCP packets.

Nginx has the functionality to work with NTLM authentication. Keepalive needs to be enabled which is only available trough the http_upstream_module. Additionally in the location block you need to specify that you will be using HTTP/1.1 and that the "Connection" header field should be cleared for each proxied request. Nginx config should look something like:

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 "";
    ...
    }
 }

I scratched my head for quite some time with this issue but the above works for me. Note that if you need to proxy HTTPS traffic, a separate upstream block is deemed necessary. To clarify a bit more, "keepalive 16;" specifies the number of simultaneous connections to the upstream your proxy is allowed to keep. Adjust the number as per the expected number of simultaneous visitors on the site.

最笨的告白 2024-10-13 18:07:06

虽然这是一篇旧文章,但我只是想报告一下,它对于我来说非常适合 Apache2.2 反向代理和 keepalive=on 选项。显然,这使代理和SharePoint主机之间的连接保持打开状态并“固定”到客户端代理连接。我不太清楚其背后的机制,但它运作得相当好。

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

解决所有问题的方法(如果您有有效的签名 SSL 证书):将 IIS 切换到基本身份验证。这绝对可以正常工作,甚至 Windows(即具有 SharePoint 连接的 Office、所有基于 WebClient 的进程等)也不会抱怨。
但是,当您仅使用不带 SSL/TLS 的 http 并且使用自签名证书时,它们就会出现。

Although this is an old post, I just want to report that it works for me quite well with an Apache2.2 reverse proxy and the keepalive=on option. Obviously, this keeps the connection between the proxy and the SharePoint host open and "pinned" to the client<>proxy connection. I don't exactly know the mechanisms behind this, but it works fairly well.

But: Sometimes, my users encounter the issue that they're logged in as another user. So there seems to be some mixing-up through sessions. I will have to give this some further testing.

Solution for everything (in case you have a valid, signed SSL certificate): Switch IIS to Basic Auth. This works absolutely fine, and even Windows (i.e. Office with SharePoint connection, all WebClient-based processes etc.) won't complain at all.
But they will when you're just using http without SSL/TLS, and also with self-signed certificates.

丢了幸福的猪 2024-10-13 18:07:06

我确认它可以在 apache2.2 上与“keep-alive=on”一起使用,

我用 Wireshark 检查了帧,我知道为什么它不起作用。如果 TCP 数据包未完全按照反向代理收到的数据包进行转发,NTLM 将无法工作。这就是为什么许多反向代理(例如 nginx)不支持 NTLM 身份验证。反向代理正确转发 HTTP 请求,但不能转发 TCP 数据包。

NTLM 需要 TCP 反向代理。

I confirm that it works with "keep-alive=on" on apache2.2

I examined frames with Wireshark, and I know why it doesn't work. NTLM won't work if the TCP packets are not forwarded exactly as the reverse proxy received them. That's why many reverse proxies, like nginx, don't work with NTLM authentication. Reverse proxies forward HTTP requests correctly but not the TCP packets.

NTLM requires a TCP reverse proxy.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文