關於整合 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身份驗證將無法運作。
我們希望本文能對在維持強大的身份驗證系統的同時，兼顧負載平衡和加密通訊的配置有所幫助。