Giới thiệu về Xác thực Windows tích hợp
Xác thực Windows tích hợp là 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 ASP.NET C#, bạn có thể xác định xem người dùng đã được xác thực hay chưa và thu thập 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 liên kết) bởi IIS mà không cần thao tác đăng nhập bổ sung và 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) nằm dưới bộ cân bằng tải và giao tiếp được mã hóa bằng SSL/TLS, xác thực Windows này có thể không hoạt động bình thường.Tại sao vậy?
Vấn đề là Xác thực Windows hoạt động như thế nào Và Hoạt động cân bằng tải nằm ở đâu.
NTLM là phương pháp xác thực thử thách/phản hồi thông qua một kết nối TCP duy nhất giữa mỗi máy khách và máy chủ. Với Kerberos, máy khách cũng sẽ nhận được vé dựa trên mã định danh dịch vụ (SPN) và gửi đến IIS. Những thông tin xác thực này được gửi qua tiêu đề HTTP (Quyền hạn: Đàm phán ... Các giao dịch được thực hiện bằng những phương pháp như vậy. 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 riêng nó, phân tích nội dung và chuyển tiếp nội dung đó đến IIS ở phía sau dưới dạng một yêu cầu mới. Trong quá trình nàyPhiên TLS đầu cuối giữa máy khách và IIS sẽ kết thúc.Hơn nữa, thông tin xác thực liên tục như NTLM không được lưu giữ, khiến quá trình xác thực không thành công.
Dựa trên bối cảnh trên, bài viết này "Bộ cân bằng tải + Cấu hình Xác thực Windows tích hợp IIS để thành công trong môi trường SSL Chúng ta sẽ xem xét những điều sau. Chúng tôi sẽ liệt kê ba mẫu cấu hình điển hình và giải thích từng mẫu xem xác thực Windows có được hỗ trợ hay không, lý do kỹ thuật cho việc này cũng như ưu điểm và nhược điểm của từng cấu hình.
Kiểm tra kỹ thuật của từng kế hoạch cấu hình
①: Bộ cân bằng tải L7 chấm dứt SSL + 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)
Khả dụng
Cấu hình này không hỗ trợ xác thực Windows.Không có sẵnlà.
lý do
Bởi vì phiên TLS giữa máy khách và IIS bị chấm dứt một lần trên bộ cân bằng tải,Không thể chuyển giao thông tin xác thực từ đầu đến cuốiĐó là lý do tại sao. Bộ cân bằng tải L7 giải mã lưu lượng HTTPS đã nhận và truy cập IIS thay mặt cho máy khách. Vào thời điểm này, khách hàng nên gửi Quyền hạn: Đàm phán Tiêu đề (tiêu đề xác thực bao gồm phiếu Kerberos và mã thông báo NTLM) sẽ không đến được IIS một cách chính xác. Cụ thể, 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 (WWW-Xác thực) khách hàng gửi lại yêu cầu, nhưng thông qua LBPhiên TCP giống nhau không được duy trìDo đó, bắt tay NTLM 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 Balancer (ALB) hoặc trình lắng nghe HTTP và cần có LB cấp TCP như Network Load Balancer (NLB).thẩm quyền giải quyết]. Ngoài ra, Azure Application Gateway v2 không hỗ trợ việc truyền tiêu đề HTTP bao gồm xác thực tích hợp đến phần phụ trợ.thẩm quyền giải quyết].
Thực tế là nó không được hỗ trợ chính thức bởi các LB được quản lý của từng nhà cung cấp dịch vụ đám mây cho thấy khó khăn trong việc duy trì xác thực Windows ở cấp L7.
②: Bộ cân bằng tải L4 (chuyển tiếp TLS)
Máy khách ──HTTPS──▶ Bộ cân bằng tải L4 (chuyển tiếp TLS) ──HTTPS──▶ IIS (443)
Khả dụng
Cấu hình này sử dụng xác thực Windows.Tương thíchlà.
lý do
Vì bộ cân bằng tải L4 (LB hoạt động ở Lớp 4 của OSI) chuyển tiếp các gói tin ở cấp TCP,Phiên TLS giữa máy khách và IIS được duy trì từ đầu đến cuốisẽ được thực hiện. Bộ cân bằng tải không chấm dứt mã hóa mà chỉ phân phối kết nối TCP tới từng máy chủ, do đó "giao tiếp trên cùng một kết nối TCP" theo yêu cầu xác thực NTLM được duy trì. Đối với Kerberos, theo quan điểm của khách hàng, nó có thể được tái tạo như thể khách hàng đang kết nối trực tiếp đến FQDN của IIS (dịch vụ), do đó, miễn là SPN được thiết lập phù hợp, xác thực dựa trên phiếu sẽ tiếp tục diễn ra như bình thường. Chế độ trình lắng nghe LB TCP cổ điển và AWS NLB, bộ cân bằng tải nội bộ Azure, chế độ F5 L4, v.v. thuộc về danh mục này (những danh mục khác bao gồm chế độ HAProxy TCP và luồng nginx) và có thể vượt qua xác thực tích hợp của Windows.
công lao
Phiên TLS không bị gián đoạn từ máy khách đến máy chủ.Các giao thức xác thực của Windows vẫn tiếp tục hoạt động như bình thườngCó thể. Quá trình bắt tay ba chiều NTLM cũng được hoàn tất trong một kết nối duy nhất và phiếu Kerberos được máy chủ phụ trợ nhận chính xác. Ngoài ra, vì LB là hoạt động L4 nên có chi phí thấp và có thể đạt được thông lượng cao.
Điểm trừ
Thách thức lớn nhất khi 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ụ, trong đường dẫn URL (ví dụ:/api,/trò chuyệnPhân phối từng yêu cầu (hoặc nhiều yêu cầu) đến một máy chủ phụ trợ khác nhau là 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 của hệ thống, có thể cần phải chuẩn bị nhiều FQDN và chỉ định các máy chủ ảo khác nhau cho các mục đích khác nhau (máy chủ web, máy chủ xác thực Windows, v.v.) trong bộ cân bằng tải, điều này có nhược điểm là làm cho việc cấu hình trở nên khó khăn hơn.
Ngoài ra, xin lưu ý rằng các thiết lập sau đây là bắt buộc để xác thực Windows đều thiết lập FQDN của bộ cân bằng tải.
- Xác thực Windows là bắt buộc trong tab "Bảo mật" của Tùy chọn Internet."Mạng nội bộ" "Các trang web" cài đặt
- Khi truy cập trang xác thực Windows bằng FQDN (tên miền đủ điều kiện) Đăng ký SPN
- Chứng chỉ SSL trong cài đặt liên kết trang web IIS
* Nếu FQDN của bộ cân bằng tải là lb.example.com, luồng cho đến khi Kerberos thành công sẽ 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 kết thúc SSL của bộ cân bằng tải L7 + chuyển hướng
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 443)
Khả dụng
Cấu hình này sử dụng xác thực Windows.Tương thíchlà.
lý do
Ý tưởng là bộ cân bằng tải không chuyển tiếp thông tin liên lạc thực tế mà chuyển hướng máy khách trực tiếp đến IIS phụ trợ (phản hồi HTTP 302). Lần đầu tiên người dùng truy cập URL LB, bộ cân bằng tải L7 sẽ chấm dứt SSL tại đó, phân tích nội dung và trả về phản hồi 302 với tiêu đề Vị trí để kết nối với địa chỉ IIS thích hợp (ví dụ: tên máy chủ riêng lẻ hoặc địa chỉ IP cho mỗi IIS) qua HTTPS. Trình duyệt của khách hàng nhận được lệnh chuyển hướng này và tự động gửi lại yêu cầu qua HTTPS trực tiếp đến IIS đã chỉ định.
kết quả,Đối với yêu cầu thứ hai, máy khách và IIS kết nối trực tiếp qua TLSDo đó, thông tin xác thực Kerberos/NTLM được truyền từ đầu đến cuối theo nguyên trạng. Vì bộ cân bằng tải không can thiệp trong quá trình xác thực nên có thể tránh được vấn đề mất tiêu đề xác thực như đã thấy trong cấu hình 1.
công lao
Một lợi thế lớn là TLS được kết nối trực tiếp từ máy khách tới IIS, giúp xác thực Windows dễ dàng thành công.là.
Nếu xác thực thành công chỉ bằng IIS, cấu hình có thể được sử dụng như hiện tại, do đó không có sự gia tăng độ khó ngay cả khi sử dụng bộ cân bằng tải làm trung gian.
Ngoài ra, bằng cách sử dụng chuyển hướng, có thể kiểm soát định tuyến ở một mức độ linh hoạt nhất định trên phía bộ cân bằng tải. Ví dụ, bạn có thể đạt được điều gì đó gần giống với phân phối theo đường dẫn 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ủ. Nếu có nhiều dịch vụ trong LB, trước tiên có thể tổng hợp chúng vào LB như một điểm vào chung, sau đó hướng người dùng đến các URL thực tế của từng dịch vụ từ đó, làm cho chúng xuất hiện như một trên bề mặt.
Điểm trừ
Nhược điểm là IIS không thể triển khai sau LB và phải thiết kế một điểm cuối riêng cho IIS như một máy chủ công cộng và phải đặt một chứng chỉ khác cho LB.
Một nhược điểm khác là việc chuyển hướng sẽ xảy ra khi truy cập lần đầu, nhưng trên thực tế, việc kết nối lại ngay lập tức được thực hiện thông qua phản hồi HTTP 302, do đó tác động đến trải nghiệm của người dùng hầu 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à trải qua xác thực Windows, hãy xem tại đâybộ phimVui lòng tham khảo trước.
Bảng so sánh từng cấu hình
| thành phần | Tổng quan | Xác thực Windows | nhận xét |
|---|---|---|---|
| ① | Kết thúc SSL tại L7 LB → IIS | ❌ Không | ・Phân tách TLS, không truyền NTLM/Kerberos |
| ② | Chuyển tiếp TLS tại L4 LB | ✅ Có | - Không thể định tuyến theo đường dẫn, do đó nhiều máy chủ ảo được hợp nhất thành một LB ・Không có tài liệu chính thức chính xác nên rất khó để ・Thiết lập chứng chỉ cho bộ cân bằng tải |
| ③ | Chuyển hướng các trang xác thực trực tiếp đến IIS | ✅ Có | - IIS không thể triển khai được phía sau LB - Cần có thiết kế điểm cuối riêng cho IIS và chứng chỉ khác với LB ・Bộ cân bằng tải L7 cho phép phân bổ theo đường dẫn |
bản tóm tắt
Để xác thực Windows (NTLM/Kerberos) hoạt động bình thường, điều bắt buộc là phiên TLS phải được duy trì xuyên suốt từ máy khách đến IIS.
Trong cấu hình bộ cân bằng tải L4 của tùy chọn 2, TLS không được chuyển tiếp và truyền trực tiếp đến IIS, do đó xác thực thành công. Tuy nhiên, cấu hình khá phức tạp vì không cho phép định tuyến theo đường dẫn chi tiết và yêu cầu cấu hình nhiều máy chủ ảo trong bộ cân bằng tải.
Mặt khác, cấu hình chuyển hướng trong Tùy chọn 3 chỉ được bộ cân bằng tải L7 xử lý lần đầu tiên, sau đó kết nối trực tiếp đến IIS, đây là luồng lý tưởng theo quan điểm của TLS và xác thực. Bằng cách chuyển hướng các đường dẫn cụ thể đến IIS FQDN, bạn có thể đạt được cả quyền kiểm soát quy tắc L7 và xác thực Windows. Cần phải kiểm tra xem có vấn đề chính sách nào liên quan đến việc không thể triển khai IIS sau LB hay không.
Mặt khác, trong cấu hình như Tùy chọn 1, trong đó bộ cân bằng tải L7 thực hiện chấm dứt TLS hoặc diễn giải HTTP, thông tin xác thực bị gián đoạn và xác thực Windows không hoạt động.
Chúng tôi hy vọng rằng bài viết này sẽ hữu ích trong việc xem xét cấu hình đạt được cả cân bằng tải và truyền thông được mã hóa trong khi vẫn duy trì hệ thống xác thực mạnh mẽ.