如何配置 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 驗證 (NTLM/Kerberos) 正常運作，必須從用戶端到 IIS 一直維護 TLS 工作階段。

在選項 2 的 L4 負載平衡器配置中，TLS 無需中繼，直接到達 IIS，因此驗證成功。但是，配置很複雜，因為它不允許詳細的基於路徑的路由，並且需要在負載平衡器內配置多個虛擬伺服器。

另一方面，選項 3 中的重定向配置僅在第一次由 L7 負載平衡器處理，然後直接連接到 IIS，從 TLS 和身份驗證的角度來看，這是理想的流程。透過將特定路徑重新導向到 IIS FQDN，您可以實現 L7 規則控制和 Windows 驗證。需要檢查是否存在無法在 LB 後面部署 IIS 的政策問題。

另一方面，在選項 1 這樣的配置中，L7 負載平衡器執行 TLS 終止或 HTTP 解釋，驗證資訊被中斷，Windows 驗證不起作用。

我們希望本文能幫助您考慮一種既能實現負載平衡又能加密通訊、同時又能保持強大的身份驗證系統的配置。