菜单

如何配置 IIS 集成 Windows 身份验证以在负载平衡器 + SSL 环境中成功

目录

关于集成 Windows 身份验证

集成 Windows 身份验证是一种当 IIS 和用户属于同一个 Active Directory 域时自动向 IIS 提供用户身份验证信息的机制。当您使用 ASP.NET C# 创建站点时,您可以确定用户是否已经过身份验证并获取有关已经过身份验证的用户的信息。

这允许用户访问 IIS 托管(或链接)的 Web 应用程序,而无需额外的登录操作,并支持与其他应用程序服务器的 SSO 集成。

但是,在 Web 服务器(IIS)位于负载均衡器下且通信使用 SSL/TLS 加密的环境中,此 Windows 身份验证可能无法正常工作。这是为什么?

如果 Windows 身份验证成功,您将能够无缝访问身份验证站点,但如果失败,则会显示登录拨号。如果您未能正确验证,您将收到 HTTP 错误 401.1 – 未授权。

重点是 Windows 身份验证的工作原理负载均衡器操作 位于。

NTLM 是一种通过每个客户端和服务器之间的单个 TCP 连接进行的质询/响应身份验证方法。使用 Kerberos,客户端还可以根据服务标识符 (SPN) 获取票证并将其发送给 IIS。这些凭证通过 HTTP 标头发送(授权:协商... 交易就是采用这种方法进行的。但是,第 7 层负载均衡器会在其自己的设备上终止来自客户端的 HTTPS 连接,分析内容,并将其作为新请求转发到后端 IIS。在此过程中客户端和 IIS 之间的端到端 TLS 会话终止。此外,NTLM 等持久身份验证信息不会被继承,从而导致身份验证过程失败。

鉴于上述背景,本文 ."负载均衡器 + 配置 IIS 集成 Windows 身份验证以在 SSL 环境中成功 我们将考虑以下内容。我们将列出三种典型的配置模式,并针对每种模式解释是否支持 Windows 身份验证、支持的技术原因以及配置的优缺点。

各配置方案技术验证

①:L7负载均衡器SSL终止+IIS(80或443)

客户端 ──HTTPS──▶ L7 负载均衡器(SSL 终止)──HTTP(S)──▶ IIS(80 或 443)

可用性

此配置不支持 Windows 身份验证。无法使用

原因

由于客户端与 IIS 之间的 TLS 会话在负载均衡器上一旦终止,无法实现端到端凭证传输这就是原因。 L7 负载均衡器解密收到的 HTTPS 流量并代表客户端访问 IIS。此时,客户端应该发送 授权方式:协商 标头(包括 Kerberos 票证和 NTLM 令牌的身份验证标头)将无法正确到达 IIS。具体来说,使用 NTLM,IIS 向初始请求发送的身份验证质询响应 (万维网认证)客户端发送重新请求,但通过 LB未维持相同的 TCP 会话因此,NTLM 握手没有成功。

事实上,即使在 AWS 环境中,Windows 身份验证也不适用于应用程序负载均衡器 (ALB) 或 HTTP 侦听器,需要网络负载均衡器 (NLB) 等 TCP 级 LB。参考资料]。此外,Azure 应用程序网关 v2 不支持将包括集成身份验证在内的 HTTP 标头传递到后端。参考资料]。

事实上,它并未得到每个云供应商的托管 LB 的官方支持,这表明在 L7 级别维护 Windows 身份验证非常困难。

②:L4负载均衡器(TLS直通)

客户端 ──HTTPS──▶ L4 负载均衡器 (TLS 直通) ──HTTPS──▶ IIS (443)

可用性

此配置使用 Windows 身份验证。兼容的

原因

由于 L4 负载均衡器(在 OSI 第 4 层运行的 LB)在 TCP 级别中继数据包,客户端和 IIS 之间的 TLS 会话是端到端维护的将会完成。负载均衡器不会终止加密,而只是简单地将 TCP 连接本身分发到每个服务器,因此维持了 NTLM 身份验证所需的“在同一个 TCP 连接上进行通信”。至于 Kerberos,从客户端的角度来看,它可以被重现,就好像客户端直接连接到 IIS(服务)的 FQDN 一样,因此只要适当地设置 SPN,基于票证的身份验证就会按原样进行。 AWS NLB 和经典 LB TCP 侦听器模式、Azure 内部负载均衡器、F5 L4 模式等属于此类(其他包括 HAProxy TCP 模式和 nginx 流),并且可以通过 Windows 集成身份验证。

好处

从客户端到服务器的 TLS 会话不会中断。Windows 身份验证协议继续正常工作能。 NTLM 三次握手也在单个连接内完成,并且 Kerberos 票证被后端服务器正确接收。此外,由于LB是L4操作,因此其开销较低,并且可以预期实现高吞吐量。

赏罚

配置 L4 负载均衡器的最大挑战是无法执行详细的基于路径或基于主机名的路由。例如,在 URL 路径中(例如/api,,/聊天将每个请求(或多个请求)分发到不同的后端服务器是只有 L7(HTTP)才能实现的功能,而 L4(TCP)则无法实现。

因此,根据系统要求,可能需要准备多个 FQDN,并在负载平衡器内为不同用途(Web 服务器、用于 Windows 身份验证的服务器等)分配不同的虚拟服务器,这会带来使配置更加困难的缺点。

另外,请注意,Windows 身份验证所需的以下设置均设置负载均衡器的 FQDN。

  • Internet 选项的“安全”选项卡中需要进行 Windows 身份验证。“本地 Intranet” “站点” 环境
  • 使用 FQDN(完全限定域名)访问 Windows 身份验证页面时 SPN 注册
  • IIS 站点绑定设置中的 SSL 证书

* 如果负载均衡器 FQDN 为 lb.example.com,则 Kerberos 成功之前的流程如下:

[Client]
  | 1. DNS解決: lb.example.com → LB
  |
  | 2. Kerberos: SPN = HTTP/lb.example.com
  |             → ドメインコントローラーにTGSを要求
  |
  | 3. TLSハンドシェイク: SNI = lb.example.com
  |             → IISで一致する証明書必要
  |
  | 4. リクエスト送信: Hostヘッダ = lb.example.com
[IIS]
  → SPN受け入れOK、証明書OK、認証成功

③:L7负载均衡器SSL终止+重定向配置

客户端 ──HTTPS──▶ L7 负载均衡器(SSL 终止)
LB ──HTTP 302(重定向响应)→客户端
客户端──HTTPS──▶ IIS(直接访问 443)

可用性

此配置使用 Windows 身份验证。兼容的

原因

其理念是,负载均衡器不会中继实际通信,而是将客户端直接重定向到后端 IIS(HTTP 302 响应)。用户第一次访问 LB URL 时,L7 负载均衡器会在那里终止 SSL、分析内容并返回带有 Location 标头的 302 响应,以通过 HTTPS 连接到适当的 IIS 地址(例如,每个 IIS 的单独主机名或 IP 地址)。客户端浏览器接收此重定向并自动通过 HTTPS 将请求直接重新提交到指定的 IIS。

结果,对于第二个请求,客户端和 IIS 通过 TLS 直接连接因此,Kerberos/NTLM 身份验证信息按原样端到端传递。由于负载均衡器在身份验证过程中不会进行干预,因此可以避免配置 1 中出现的身份验证头丢失的问题。

好处

一个主要的优点是 TLS 直接从客户端连接到 IIS,使 Windows 身份验证很容易成功。
如果单独使用 IIS 进行身份验证成功,则可以按原样使用配置,因此即使使用负载平衡器作为中介,也不会增加难度。

此外,通过利用重定向,可以在负载均衡器端实现一定程度的灵活路由控制。例如,您可以根据初始访问 URL 路径或主机名重定向到不同的后端 IIS URL 来实现接近基于路径的分发。如果LB下有很多服务,那么可以先将它们聚合到LB中作为一个公共入口点,然后从那里将用户引导到每个服务的实际URL,使得它们表面上看起来像一个。

赏罚

缺点是不能将 IIS 部署在 LB 后面,必须为 IIS 设计单独的端点作为公共服务器,并且为 LB 放置不同的证书。

另一个缺点是第一次访问时会发生重定向,但实际上,通过 HTTP 302 响应立即重新连接,因此对用户体验的影响几乎可以忽略不计。

有关重定向到 IIS 并通过 Windows 身份验证后登录我们服务的速度的参考,请参见此处电影另请参见

各配置对比表

作品概述。Windows 身份验证评论
SSL 终止于 L7 LB → IIS❌ 没有・TLS 分离、NTLM/Kerberos 不传输
L4 LB 上的 TLS 直通✅ 是的- 无法进行基于路径的路由,因此多个虚拟服务器被合并为一个 LB
・没有准确的官方文献,因此很难
・为负载均衡器设置证书
将身份验证页面直接重定向到 IIS✅ 是的- IIS 不能部署在 LB 后面
- 需要为 IIS 设计单独的端点,并使用来自 LB 的不同证书
・L7 负载均衡器允许基于路径的分配
各配置对比表

摘要

为了使 Windows 身份验证 (NTLM/Kerberos) 正常工作,必须从客户端到 IIS 一直维护 TLS 会话。

在选项 2 的 L4 负载均衡器配置中,TLS 无需中继,直接到达 IIS,因此身份验证成功。但是,配置很复杂,因为它不允许详细的基于路径的路由,并且需要在负载平衡器内配置多个虚拟服务器。

另一方面,选项 3 中的重定向配置仅在第一次由 L7 负载均衡器处理,然后直接连接到 IIS,从 TLS 和身份验证的角度来看,这是理想的流程。通过将特定路径重定向到 IIS FQDN,您可以实现 L7 规则控制和 Windows 身份验证。需要检查是否存在无法在 LB 后面部署 IIS 的策略问题。

另一方面,在选项 1 这样的配置中,L7 负载均衡器执行 TLS 终止或 HTTP 解释,身份验证信息被中断,Windows 身份验证不起作用。

我们希望本文能够帮助您考虑一种既能实现负载平衡又能加密通信、同时又能保持强大的身份验证系统的配置。

  • URLをコピーしました!
目录