Giới thiệu về Xác thực Windows tích hợp
Xác thực Windows tích hợp là một cơ chế tự động cung cấp thông tin xác thực người dùng cho IIS khi IIS và người dùng thuộc cùng một miền Active Directory. Khi bạn tạo một trang web bằng C# của ASP.NET, bạn có thể xác định xem người dùng đã được xác thực hay chưa và truy xuất thông tin về những người dùng đã được xác thực.
Điều này cho phép người dùng truy cập các ứng dụng web được lưu trữ (hoặc tích hợp với) IIS mà không cần thực hiện thêm các bước đăng nhập, đồng thời cho phép tích hợp SSO với các máy chủ ứng dụng khác.
Tuy nhiên, trong môi trường mà máy chủ web (IIS) được đặt dưới bộ cân bằng tải và giao tiếp được mã hóa bằng SSL/TLS, có những trường hợp xác thực Windows này không hoạt động chính xác.Tại sao lại như vậy?
Điểm mấu chốt là Cơ chế xác thực Windows と Hoạt động cân bằng tải Nó nằm ở đó.
NTLM là một phương thức xác thực thực hiện thách thức/phản hồi trên một kết nối TCP duy nhất giữa mỗi máy khách và máy chủ. Tương tự, với Kerberos, máy khách nhận được một vé dựa trên Tên Nhà cung cấp Dịch vụ (SPN) và gửi nó đến IIS. Thông tin xác thực này sau đó được nhập vào tiêu đề HTTP.Ủy quyền: Đàm phán... Dữ liệu sau đó được truyền qua (v.v.). Tuy nhiên, bộ cân bằng tải lớp 7 sẽ chấm dứt kết nối HTTPS từ máy khách trên thiết bị của chính nó, phân tích nội dung và chuyển tiếp nó đến máy chủ IIS phía máy chủ dưới dạng một yêu cầu mới.Phiên TLS đầu cuối giữa máy khách và IIS đã bị ngắt kết nối.Hơn nữa, vì thông tin xác thực duy trì kết nối, chẳng hạn như thông tin được sử dụng bởi NTLM, không được chuyển tiếp, nên quá trình xác thực thất bại.
Dựa trên bối cảnh nêu trên, bài viết này sẽ thảo luận về... 「Bộ cân bằng tải "Cấu hình để triển khai thành công xác thực Windows tích hợp IIS trong môi trường SSL." Chúng ta sẽ xem xét vấn đề này. Chúng ta sẽ trình bày ba mô hình cấu hình điển hình và giải thích xem xác thực Windows có được hỗ trợ cho từng mô hình hay không, lý do kỹ thuật cho điều này, cũng như ưu điểm và nhược điểm của mỗi cấu hình.
Kiểm tra kỹ thuật từng cấu hình.
①: Bộ cân bằng tải L7, chấm dứt SSL + chuyển tiếp đến IIS (80 hoặc 443)
Máy khách ──HTTPS──▶ Bộ cân bằng tải L7 (Chấm dứt SSL) ──HTTP(S)──▶ IIS (80 hoặc 443)
Tính khả dụng
Xác thực Windows trong cấu hình nàyKhông khả dụnglà.
lý do
Vì phiên TLS giữa máy khách và IIS bị chấm dứt ngay khi đến bộ cân bằng tải,Việc truyền tải thông tin xác thực đầu cuối là không thể.Điều này là do bộ cân bằng tải L7 giải mã HTTPS nhận được và truy cập IIS thay mặt cho máy khách. Tại thời điểm này, dữ liệu lẽ ra được gửi từ máy khách đến IIS lại bị... Ủy quyền: Đàm phán Các tiêu đề (bao gồm cả tiêu đề xác thực như vé Kerberos và mã thông báo NTLM) sẽ không được gửi đến IIS một cách chính xác. Đặc biệt, với NTLM, phản hồi thử thách xác thực mà IIS gửi đến yêu cầu ban đầu (Xác thực WWWDựa trên điều này, khách hàng gửi yêu cầu đã sửa đổi, nhưng thông qua LB.Phiên TCP cũ không được duy trì.Do đó, quá trình bắt tay NTLM sẽ không thành công.
Trên thực tế, ngay cả trong môi trường AWS, xác thực Windows cũng không hoạt động với Application Load Balancers (ALB) hoặc HTTP listeners, và người ta cho rằng cần đến các bộ cân bằng tải cấp TCP như Network Load Balancers (NLB).thẩm quyền giải quyếtHơn nữa, Azure Application Gateway v2 không hỗ trợ truyền các tiêu đề HTTP, bao gồm cả xác thực tích hợp, đến máy chủ phụ trợ.thẩm quyền giải quyết]。
Việc tính năng này không được hỗ trợ chính thức bởi bất kỳ nhà cung cấp dịch vụ đám mây nào trong bộ cân bằng tải được quản lý cho thấy sự khó khăn trong việc duy trì xác thực Windows ở cấp độ L7.
②: Bộ cân bằng tải L4 (truyền tải TLS) + chuyển tiếp IIS
Máy khách ──HTTPS──▶ Bộ cân bằng tải L4 (Truyền qua TLS) ──HTTPS──▶ IIS (443)
Tính khả dụng
Cấu hình này dành cho xác thực Windows.Có sẵnlà.
lý do
Bộ cân bằng tải L4 (bộ cân bằng tải hoạt động ở lớp 4 của mô hình OSI) chuyển tiếp các gói tin ở cấp độ TCP.Phiên giao dịch TLS giữa máy khách và IIS được duy trì từ đầu đến cuối.Điều này là do bộ cân bằng tải không chấm dứt mã hóa, mà chỉ đơn giản là phân phối kết nối TCP đến từng máy chủ, do đó duy trì "giao tiếp trên cùng một kết nối TCP" cần thiết cho xác thực NTLM. Tương tự, đối với Kerberos, nó mô phỏng trải nghiệm của máy khách khi kết nối trực tiếp với FQDN của IIS (dịch vụ), vì vậy xác thực dựa trên vé hoạt động miễn là SPN được cấu hình chính xác. AWS NLB và Classic LB ở chế độ nghe TCP, bộ cân bằng tải nội bộ của Azure và chế độ L4 của F5 thuộc loại này (các loại khác bao gồm chế độ TCP của HAProxy và luồng nginx), và có thể bỏ qua xác thực tích hợp của Windows.
công lao
Vì phiên TLS không bị gián đoạn từ phía máy khách đến máy chủ,Giao thức xác thực Windows vẫn duy trì chức năng vốn có của nó.Vâng, điều đó hoàn toàn có thể. Quá trình bắt tay ba bước NTLM được hoàn tất trong một kết nối duy nhất, và vé Kerberos được máy chủ phụ trợ nhận chính xác. Ngoài ra, vì bộ cân bằng tải hoạt động ở lớp L4, nên nó có chi phí vận hành thấp và có thể kỳ vọng thông lượng cao.
Nhược điểm
Thách thức lớn nhất với cấu hình bộ cân bằng tải L4 là không thể thực hiện định tuyến chi tiết dựa trên đường dẫn hoặc tên máy chủ. Ví dụ: đường dẫn URL (ví dụ:/api、/chatPhân phối các yêu cầu đến các máy chủ phụ trợ khác nhau dựa trên nhu cầu cụ thể của chúng là một tính năng chỉ có thể thực hiện được với L7 (HTTP) và không thể thực hiện được với L4 (TCP).
Do đó, tùy thuộc vào yêu cầu hệ thống, có thể cần phải chuẩn bị nhiều FQDN và gán các máy chủ ảo khác nhau (chẳng hạn như máy chủ web và máy chủ xác thực Windows) cho bộ cân bằng tải cho mỗi mục đích, điều này có nhược điểm là làm tăng độ phức tạp của cấu hình.
Cụ thể, khi truy cập trang xác thực Windows bằng tên miền đủ điều kiện (FQDN). Đăng ký SPN Vấn đề này khá phức tạp, vì vậy vui lòng kiểm tra thêm các thông tin sau.
Ngoài ra, xin lưu ý rằng tất cả các thiết lập cần thiết cho xác thực Windows sau đây phải được đặt thành tên miền đầy đủ (FQDN) của bộ cân bằng tải.
- Bạn cần mở tab "Bảo mật" trong Tùy chọn Internet để xác thực Windows."Trang web" trên "mạng nội bộ cục bộ" cài đặt
- Cấu hình liên kết trang web IIS và chứng chỉ SSL (không cần cài đặt chứng chỉ trên chính bộ cân bằng tải).
Quy trình theo sơ đồ lưu trình cho đến khi thành công
Nếu tên miền đầy đủ (FQDN) của bộ cân bằng tải là lb.example.com, quy trình cho đến khi Kerberos thành công sẽ diễn ra như sau:
[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、認証成功③: Cấu hình chấm dứt SSL và chuyển hướng đến IIS trên bộ cân bằng tải L7
Máy khách ──HTTPS──▶ Bộ cân bằng tải L7 (Chấm dứt SSL)
LB ── HTTP 302 (Phản hồi chuyển hướng) → Máy khách
Máy khách ──HTTPS──▶ IIS (truy cập trực tiếp vào cổng 443)
Tính khả dụng
Cấu hình này dành cho xác thực Windows.Có sẵnlà.
lý do
Ý tưởng là bộ cân bằng tải không chuyển tiếp quá trình giao tiếp thực tế, mà thay vào đó chuyển hướng máy khách trực tiếp đến máy chủ IIS phía máy chủ thông qua phản hồi HTTP 302. Ban đầu, người dùng truy cập URL của bộ cân bằng tải, nhưng bộ cân bằng tải lớp 7 sẽ phân tích nội dung trong khi chấm dứt kết nối SSL tại đó và trả về phản hồi 302 với tiêu đề Location hướng dẫn người dùng kết nối qua HTTPS đến địa chỉ IIS thích hợp (ví dụ: tên máy chủ hoặc địa chỉ IP riêng của mỗi máy chủ IIS). Trình duyệt của máy khách nhận được lệnh chuyển hướng này và tự động gửi lại yêu cầu trực tiếp đến máy chủ IIS được chỉ định qua HTTPS.
kết quả,Trong yêu cầu thứ hai, máy khách và IIS kết nối trực tiếp với nhau thông qua TLS.Do đó, thông tin xác thực Kerberos/NTLM cũng được trao đổi nguyên vẹn từ đầu đến cuối. Vì bộ cân bằng tải không can thiệp trong quá trình xác thực, nên vấn đề mất tiêu đề xác thực được thể hiện trong sơ đồ cấu hình ① có thể được tránh.
công lao
Một ưu điểm lớn là TLS thiết lập kết nối trực tiếp từ máy khách đến IIS, giúp việc xác thực Windows trở nên dễ dàng hơn nhiều.là.
Nếu quá trình xác thực thành công chỉ với IIS, cấu hình đó có thể được sử dụng như hiện trạng, vì vậy việc thêm bộ cân bằng tải sẽ không làm tăng thêm độ khó.
Hơn nữa, bằng cách sử dụng chuyển hướng, bộ cân bằng tải có thể thực hiện một mức độ kiểm soát định tuyến linh hoạt. Ví dụ, bằng cách chuyển hướng đến các URL IIS phụ trợ khác nhau tùy thuộc vào đường dẫn URL truy cập ban đầu hoặc tên máy chủ, có thể đạt được điều gì đó gần giống với phân phối dựa trên đường dẫn. Nếu có nhiều dịch vụ dưới bộ cân bằng tải, cũng có thể hợp nhất chúng vào một điểm truy cập chung trên bộ cân bằng tải và sau đó hướng người dùng đến các URL thực tế của từng dịch vụ, làm cho nó xuất hiện như một thực thể duy nhất trên bề mặt.
Nhược điểm
Một nhược điểm là IIS không thể được triển khai phía sau bộ cân bằng tải, đòi hỏi thiết kế điểm cuối riêng biệt cho IIS như một máy chủ công cộng, và yêu cầu vị trí chứng chỉ khác so với bộ cân bằng tải.
Một nhược điểm khác là việc chuyển hướng xảy ra khi truy cập lần đầu, nhưng trên thực tế, điều này chỉ đơn giản là kết nối lại ngay lập tức thông qua phản hồi HTTP 302, và tác động đến trải nghiệm người dùng gần như không đáng kể.
Để tham khảo về tốc độ đăng nhập vào dịch vụ của chúng tôi sau khi chuyển hướng đến IIS và xác thực Windows, vui lòng xem tại đây.bộ phimVui lòng tham khảo những thông tin sau.
Bảng so sánh từng cấu hình
| bố cục | Tổng quan | Xác thực Windows | nhận xét |
|---|---|---|---|
| ① | L7 LB (chấm dứt SSL) → IIS | ❌ Không thể | • Tách biệt TLS, không truyền NTLM/Kerberos |
| ② | L4 LB (truyền tải TLS) → IIS | ✅ Có thể | - Không thể sử dụng định tuyến dựa trên đường dẫn; việc định tuyến được thực hiện bằng cách cấu hình các máy chủ ảo trên bộ cân bằng tải bằng cách sử dụng nhiều tên miền đủ điều kiện (FQDN). - Cấu hình chứng chỉ ở phía IIS (không cần chứng chỉ trên bộ cân bằng tải). - Cổng 443 của IIS chỉ được phép nhận các kết nối đến từ bộ cân bằng tải. - Nhìn chung, có rất ít tài liệu chính thức, điều này gây khó khăn. |
| ③ | L7 LB (Chấm dứt SSL) → Chuyển hướng đến IIS | ✅ Có thể | • Có thể định tuyến dựa trên đường dẫn. Cần có chứng chỉ ở cả phía IIS và bộ cân bằng tải. - Cho phép các kết nối đến trên cổng 443 của IIS với tùy chọn ANY. - Việc kiểm thử có thể được thực hiện chỉ bằng IIS, giúp giảm bớt độ phức tạp. |
bản tóm tắt
Để quá trình xác thực Windows (NTLM/Kerberos) hoạt động chính xác, việc duy trì phiên TLS liên tục từ máy khách đến IIS là vô cùng cần thiết.
Trong cấu hình bộ cân bằng tải L4 của tùy chọn ②, quá trình xác thực thành công vì TLS không được chuyển tiếp và lưu lượng truy cập đi thẳng đến IIS. Tuy nhiên, việc không thể thực hiện định tuyến dựa trên đường dẫn chi tiết và cần phải cấu hình nhiều máy chủ ảo trong bộ cân bằng tải khiến việc cấu hình trở nên khó khăn hơn.
Mặt khác, cấu hình chuyển hướng trong tùy chọn ③ là lý tưởng từ góc độ TLS và xác thực, vì nó xử lý yêu cầu ban đầu bằng bộ cân bằng tải L7 và sau đó kết nối trực tiếp với IIS. Bằng cách chuyển hướng các đường dẫn cụ thể đến FQDN của IIS, có thể đạt được cả kiểm soát quy tắc L7 và xác thực Windows. Cần kiểm tra xem có bất kỳ vấn đề nào về chính sách với IIS, nếu IIS không nằm sau bộ cân bằng tải, cho phép cổng 443 với ANY hay không.
Ngược lại, trong cấu hình như tùy chọn ①, nơi bộ cân bằng tải L7 can thiệp vào việc chấm dứt TLS hoặc diễn giải HTTP, thông tin xác thực sẽ bị gián đoạn và quá trình xác thực Windows sẽ không hoạt động.
Chúng tôi hy vọng bài viết này sẽ hữu ích trong việc xem xét các cấu hình cân bằng giữa cân bằng tải và giao tiếp mã hóa, đồng thời duy trì một hệ thống xác thực mạnh mẽ.