关于集成 Windows 身份验证
集成 Windows 身份验证是一种机制，当 IIS 和用户属于同一个 Active Directory 域时，它会自动向 IIS 提供用户身份验证信息。使用 ASP.NET 的 C# 创建站点时，您可以确定用户是否已通过身份验证，并检索有关已通过身份验证用户的信息。
这样，用户无需额外的登录步骤即可访问托管在 IIS 上（或与 IIS 集成）的 Web 应用程序，并可与其他应用程序服务器实现 SSO 集成。
然而，在 Web 服务器 (IIS) 位于负载均衡器下，并且通信使用 SSL/TLS 加密的环境中，有时 Windows 身份验证无法正常工作。这是为什么？
关键点是 Windows 身份验证机制 と 负载均衡器运行 它就位于那里。
NTLM 是一种身份验证方法，它通过客户端和服务器之间的单个 TCP 连接执行质询/响应。类似地，Kerberos 中，客户端根据服务提供商名称 (SPN) 获取票证并将其发送到 IIS。然后，此身份验证信息会被添加到 HTTP 标头中。授权：协商……. 数据随后通过（等等）进行传输。然而，第 7 层负载均衡器会在其自身设备上终止来自客户端的 HTTPS 连接，分析内容，并将其作为新请求转发到后端 IIS。客户端与 IIS 之间的端到端 TLS 会话已断开。此外，由于连接持久性身份验证信息（例如 NTLM 使用的信息）无法传递，因此身份验证过程失败。
基于以上背景，本文将探讨 「负载均衡器 “在 SSL 环境中成功实现 IIS 集成 Windows 身份验证的配置。” 我们将对此进行探讨。我们将介绍三种典型的配置模式，并解释每种模式是否支持 Windows 身份验证、其技术原因以及每种配置的优缺点。
对每种配置进行技术验证
①：L7负载均衡器SSL终止+转发至IIS（80或443端口）
客户端 ──HTTPS──▶ L7 负载均衡器（SSL 终止） ──HTTP(S)──▶ IIS（80 或 443）
可用性
此配置中的 Windows 身份验证不可用是。
原因
因为客户端和 IIS 之间的 TLS 会话在负载均衡器上终止一次，无法进行端到端的身份验证信息传输。这是因为 L7 负载均衡器会解密接收到的 HTTPS 请求，并代表客户端访问 IIS。此时，通常由客户端发送到 IIS 的数据会被…… 授权：协商 标头（包括身份验证标头，例如 Kerberos 票据和 NTLM 令牌）将无法正确到达 IIS。特别是对于 NTLM，IIS 发送给初始请求的身份验证质询响应（WWW-身份验证基于此，客户端发送了一个修改后的请求，但这次是通过负载均衡器发送的。TCP 会话未保持在同一会话中。因此，NTLM握手将不会成功。
事实上，即使在 AWS 环境中，Windows 身份验证也无法与应用程序负载均衡器 (ALB) 或 HTTP 监听器一起使用，据说需要 TCP 级别的负载均衡器，例如网络负载均衡器 (NLB)。参考此外，Azure 应用程序网关 v2 不支持将 HTTP 标头（包括集成身份验证）传递到后端。参考]。
每个云供应商的托管负载均衡器都明确表示不支持此功能，这表明在 L7 级别维护 Windows 身份验证非常困难。
②：L4负载均衡器（TLS透传）+ IIS转发
客户端 ──HTTPS──▶ L4 负载均衡器（TLS 直通） ──HTTPS──▶ IIS (443)
可用性
此配置用于 Windows 身份验证可用的是。
原因
L4负载均衡器（运行在OSI第4层的负载均衡器）在TCP层转发数据包。客户端和 IIS 之间的 TLS 会话是端到端维护的。这是因为负载均衡器不会终止加密，而只是将 TCP 连接本身分发给每个服务器，从而维持 NTLM 身份验证所需的“通过同一 TCP 连接进行通信”。类似地，对于 Kerberos，它模拟了客户端直接连接到 IIS（服务）FQDN 的体验，因此只要 SPN 配置正确，基于票据的身份验证就能正常工作。AWS NLB 和经典负载均衡器（TCP 侦听器模式）、Azure 的内部负载均衡器以及 F5 的 L4 模式都属于此类（其他包括 HAProxy 的 TCP 模式和 nginx 流），并且可以绕过 Windows 集成身份验证。
优点
因为客户端到服务器之间的TLS会话没有中断，Windows 身份验证协议保持了其预期功能。是的，这是可行的。NTLM 三次握手在单个连接内即可完成，后端服务器也能正确接收到 Kerberos 票据。此外，由于负载均衡器运行在 L4 层，因此开销低，可以预期吞吐量高。
缺点
L4 负载均衡器配置的最大挑战在于无法基于路径或主机名进行细粒度路由。例如，URL 路径（例如：/api、/聊天根据后端服务器的具体需求将请求分发到不同的后端服务器，这是只有 L7 (HTTP) 才能实现的功能，而 L4 (TCP) 则无法实现。
因此，根据系统要求，可能需要准备多个 FQDN，并为每个目的将不同的虚拟服务器（例如 Web 服务器和 Windows 身份验证服务器）分配给负载均衡器，这样做的缺点是增加了配置的复杂性。
特别是当使用 FQDN（完全限定域名）访问 Windows 身份验证页面时 SPN注册 这比较复杂，所以请同时查看以下内容。
另外，请注意，Windows 身份验证所需的所有以下设置都应设置为负载均衡器的 FQDN。
- Windows 身份验证需要启用 Internet 选项中的“安全”选项卡。“本地内网”上的“站点” 环境
- 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终止+重定向配置到IIS
客户端──HTTPS──▶ L7负载均衡器（SSL终止）
负载均衡器 ── HTTP 302（重定向响应）→ 客户端
客户端──HTTPS──▶ IIS（直接访问端口443）
可用性
此配置用于 Windows 身份验证可用的是。
原因
其原理是负载均衡器不转发实际通信，而是通过 HTTP 302 响应将客户端直接重定向到后端 IIS。最初，用户访问负载均衡器的 URL，但 L7 负载均衡器会解析内容并终止 SSL 连接，然后返回一个带有 Location 标头的 302 响应，指示用户通过 HTTPS 连接到相应的 IIS 地址（例如，每个 IIS 的主机名或 IP 地址）。客户端浏览器收到此重定向后，会自动通过 HTTPS 将请求直接发送到指定的 IIS。
结果，在第二个请求中，客户端和 IIS 通过 TLS 直接连接。因此，Kerberos/NTLM认证信息也按原样进行端到端交换。由于负载均衡器在认证过程中不进行干预，因此可以避免配置方案①中所示的认证头丢失问题。
优点
TLS 的一个主要优势是它建立了从客户端到 IIS 的直接连接，使 Windows 身份验证变得更加容易。是。
如果仅使用 IIS 进行身份验证即可成功，则可以按原样使用该配置，因此添加负载均衡器不会增加难度。
此外，通过重定向，负载均衡器可以实现一定程度的灵活路由控制。例如，根据初始访问 URL 路径或主机名重定向到不同的后端 IIS URL，可以实现接近基于路径的分发。如果负载均衡器下有多个服务，还可以将它们整合到负载均衡器的公共入口点，然后引导用户访问每个服务的实际 URL，使其在表面上看起来像一个单一实体。
缺点
缺点是 IIS 不能部署在负载均衡器后面，因此需要为 IIS 作为公共服务器单独设计端点，并且需要与负载均衡器不同的证书放置位置。
另一个缺点是首次访问时会发生重定向，但实际上，这只是通过 HTTP 302 响应立即重新连接，对用户体验的影响几乎可以忽略不计。
有关重定向到 IIS 和 Windows 身份验证后登录我们服务的速度参考，请参见此处。电影请参考以下内容。
各配置对比表
| 作品 | 概述 | Windows 身份验证 | 评论 |
|---|---|---|---|
| ① | L7 负载均衡器（SSL 终止）→ IIS | ❌ 不可能 | ・TLS分离，NTLM/Kerberos非传输 |
| ② | L4 负载均衡（TLS 直通）→ IIS | ✅ 可能 | - 无法进行基于路径的路由；路由是通过在负载均衡器上配置虚拟服务器并使用多个 FQDN 来实现的。 - 在 IIS 端配置证书（负载均衡器上不需要证书）。 - IIS 端口 443 仅允许接收来自负载均衡器的入站连接。 总体而言，官方文件很少，这使得调查工作变得困难。 |
| ③ | L7 负载均衡器（SSL 终止）→ 重定向到 IIS | ✅ 可能 | ・可以进行基于路径的路由 IIS 端和负载均衡器都需要证书。 - 允许 IIS 端口 443 上的入站连接，连接类型为 ANY。 - 仅使用 IIS 即可进行测试，这使得测试变得更容易。 |
概括
要使 Windows 身份验证（NTLM/Kerberos）正常工作，从客户端到 IIS 保持 TLS 会话的一致性至关重要。
在方案②的L4负载均衡器配置中，由于TLS未进行中继，流量直接流向IIS，因此身份验证成功。然而，由于无法执行细粒度的基于路径的路由，且需要在负载均衡器内配置多个虚拟服务器，使得配置更加复杂。
另一方面，从 TLS 和身份验证的角度来看，选项 ③ 中的重定向配置是理想的，因为它使用 L7 负载均衡器处理初始请求，然后直接连接到 IIS。通过将特定路径重定向到 IIS 的 FQDN，可以同时实现 L7 规则控制和 Windows 身份验证。需要检查 IIS 是否存在策略问题，例如未连接到负载均衡器的 IIS 是否允许端口 443 以 ANY 权限访问。
相反，在选项①这样的配置中，L7负载均衡器会干预TLS终止或HTTP解释，导致身份验证信息中断，Windows身份验证将无法工作。
我们希望本文能对在保持强大的身份验证系统的同时，兼顾负载均衡和加密通信的配置有所帮助。