การกำหนดค่าสำหรับการตรวจสอบสิทธิ์ Windows ที่ผสานรวมกับ IIS อย่างสำเร็จในสภาพแวดล้อมที่มีโหลดบาลานเซอร์และ SSL

เกี่ยวกับการตรวจสอบสิทธิ์แบบรวมของ Windows

การตรวจสอบสิทธิ์แบบรวมใน Windows (Integrated Windows Authentication หรือ IIS) เป็นกลไกที่ให้ข้อมูลการตรวจสอบสิทธิ์ผู้ใช้แก่ IIS โดยอัตโนมัติ เมื่อ IIS และผู้ใช้เป็นส่วนหนึ่งของโดเมน Active Directory เดียวกัน เมื่อคุณสร้างไซต์ด้วย C# ของ ASP.NET คุณสามารถตรวจสอบได้ว่าผู้ใช้ได้รับการตรวจสอบสิทธิ์แล้วหรือไม่ และดึงข้อมูลเกี่ยวกับผู้ใช้ที่ได้รับการตรวจสอบสิทธิ์ได้

วิธีนี้ช่วยให้ผู้ใช้สามารถเข้าถึงเว็บแอปพลิเคชันที่โฮสต์ (หรือผสานรวมเข้ากับ) IIS โดยไม่ต้องเข้าสู่ระบบเพิ่มเติม และยังช่วยให้สามารถผสานรวม SSO กับเซิร์ฟเวอร์แอปพลิเคชันอื่นๆ ได้อีกด้วย

อย่างไรก็ตาม ในสภาพแวดล้อมที่เว็บเซิร์ฟเวอร์ (IIS) อยู่ภายใต้ตัวกระจายโหลด และการสื่อสารถูกเข้ารหัสด้วย SSL/TLS อาจมีบางกรณีที่การตรวจสอบสิทธิ์ของ Windows นี้ทำงานไม่ถูกต้องทำไมถึงเป็นเช่นนั้น?

หากการตรวจสอบสิทธิ์ของ Windows สำเร็จ คุณสามารถใช้กลไกเพื่อเข้าถึงเว็บไซต์การตรวจสอบสิทธิ์ได้อย่างราบรื่น แต่หากล้มเหลว หน้าจอขอเข้าสู่ระบบจะปรากฏขึ้น นอกจากนี้ หากการตรวจสอบสิทธิ์ดำเนินการไม่ถูกต้อง จะแสดงข้อผิดพลาด HTTP 401.1 – ไม่ได้รับอนุญาต

ประเด็นสำคัญคือ กลไกการตรวจสอบสิทธิ์ของ Windows と การทำงานของโหลดบาลานเซอร์ มันตั้งอยู่ที่นั่น

NTLM เป็นวิธีการตรวจสอบสิทธิ์ที่ทำการท้าทาย/ตอบสนองผ่านการเชื่อมต่อ TCP เดียวระหว่างไคลเอ็นต์และเซิร์ฟเวอร์แต่ละฝ่าย ในทำนองเดียวกันกับ Kerberos ไคลเอ็นต์จะได้รับตั๋วโดยอิงจากชื่อผู้ให้บริการ (SPN) และส่งไปยัง IIS จากนั้นข้อมูลการตรวจสอบสิทธิ์นี้จะถูกป้อนลงในส่วนหัว HTTPการอนุมัติ: เจรจา... จากนั้นข้อมูลจะถูกส่งผ่านทาง (เป็นต้น) อย่างไรก็ตาม ตัวจัดการโหลดเลเยอร์ 7 จะยุติการเชื่อมต่อ HTTPS จากไคลเอ็นต์บนอุปกรณ์ของตนเอง วิเคราะห์เนื้อหา และส่งต่อไปยังแบ็กเอนด์ IIS ในรูปแบบคำขอใหม่การเชื่อมต่อ TLS แบบครบวงจรระหว่างไคลเอ็นต์และ IIS ถูกตัดการเชื่อมต่อแล้วนอกจากนี้ เนื่องจากข้อมูลการตรวจสอบสิทธิ์ที่คงการเชื่อมต่อไว้ เช่น ข้อมูลที่ใช้โดย NTLM ไม่ได้ถูกส่งต่อ ทำให้กระบวนการตรวจสอบสิทธิ์ล้มเหลว

จากข้อมูลเบื้องต้นข้างต้น บทความนี้จะกล่าวถึง... 「ตัวกระจายโหลด "การตั้งค่าเพื่อใช้งานการตรวจสอบสิทธิ์ Windows ที่ผสานรวมกับ IIS ในสภาพแวดล้อม SSL ได้อย่างประสบความสำเร็จ" เราจะมาตรวจสอบเรื่องนี้กัน เราจะนำเสนอรูปแบบการกำหนดค่าทั่วไปสามแบบ และอธิบายว่าแต่ละแบบรองรับการตรวจสอบสิทธิ์ของ Windows หรือไม่ เหตุผลทางเทคนิค และข้อดีข้อเสียของการกำหนดค่าแต่ละแบบ

การตรวจสอบทางเทคนิคของแต่ละการกำหนดค่า

①: ตัวจัดการโหลด L7 พร้อมการยุติ SSL และการส่งต่อไปยัง IIS (80 หรือ 443)

ไคลเอ็นต์ ──HTTPS──▶ โหลดบาลานเซอร์ L7 (การยุติ SSL) ──HTTP(S)──▶ IIS (80 หรือ 443)

ความพร้อมใช้งาน

การตรวจสอบสิทธิ์ Windows ในการตั้งค่านี้ไม่พร้อมใช้งานเป็น.

เหตุผล

เนื่องจากการเชื่อมต่อ TLS ระหว่างไคลเอ็นต์และ IIS จะถูกยกเลิกเมื่ออยู่บนโหลดบาลานเซอร์แล้วการถ่ายโอนข้อมูลการตรวจสอบสิทธิ์แบบครบวงจรนั้นเป็นไปไม่ได้เนื่องจากตัวกระจายโหลด L7 จะถอดรหัส HTTPS ที่ได้รับและเข้าถึง IIS ในนามของไคลเอ็นต์ ในขณะนี้ ข้อมูลที่ปกติจะถูกส่งจากไคลเอ็นต์ไปยัง IIS นั้น... การอนุมัติ: เจรจาต่อรอง ส่วนหัว (รวมถึงส่วนหัวการตรวจสอบสิทธิ์ เช่น ตั๋ว Kerberos และโทเค็น NTLM) จะไม่ส่งไปถึง IIS อย่างถูกต้อง โดยเฉพาะอย่างยิ่งในกรณีของ NTLM การตอบสนองการท้าทายการตรวจสอบสิทธิ์ที่ IIS ส่งไปยังคำขอเริ่มต้น (WWW-Authenticateจากข้อมูลนี้ ลูกค้าจึงส่งคำขอที่แก้ไขแล้ว แต่ส่งผ่านทาง Load Balancer (LB)เซสชัน TCP เดียวกันจะไม่คงอยู่ต่อไปดังนั้น การเชื่อมต่อแบบ NTLM จึงจะไม่สำเร็จ

ในความเป็นจริง แม้แต่ในสภาพแวดล้อม AWS การตรวจสอบสิทธิ์แบบ Windows ก็ใช้งานไม่ได้กับ Application Load Balancers (ALBs) หรือ HTTP listeners และมีการกล่าวกันว่าจำเป็นต้องใช้โหลดบาลานเซอร์ระดับ TCP เช่น Network Load Balancers (NLBs)อ้างอิงนอกจากนี้ Azure Application Gateway v2 ยังไม่รองรับการส่งส่วนหัว HTTP รวมถึงการตรวจสอบสิทธิ์แบบรวม ไปยังแบ็กเอนด์อ้างอิง]。

ข้อเท็จจริงที่ว่าระบบโหลดบาลานเซอร์แบบจัดการของแต่ละผู้ให้บริการคลาวด์ไม่รองรับฟังก์ชันนี้อย่างเป็นทางการ แสดงให้เห็นถึงความยากลำบากในการรักษาการตรวจสอบสิทธิ์ของ Windows ในระดับ L7

②: โหลดบาลานเซอร์ L4 (TLS passthrough) + การส่งต่อข้อมูล IIS

ไคลเอ็นต์ ──HTTPS──▶ โหลดบาลานเซอร์ L4 (TLS Passthrough) ──HTTPS──▶ IIS (443)

ความพร้อมใช้งาน

การตั้งค่านี้ใช้สำหรับการตรวจสอบสิทธิ์ของ Windowsมีอยู่เป็น.

เหตุผล

ตัวกระจายโหลดระดับ L4 (LB ที่ทำงานที่เลเยอร์ 4 ของ OSI) จะส่งต่อแพ็กเก็ตที่ระดับ TCPการเชื่อมต่อ TLS ระหว่างไคลเอ็นต์และ IIS จะถูกรักษาไว้ตั้งแต่ต้นจนจบเนื่องจากตัวกระจายโหลด (load balancer) ไม่ได้ยุติการเข้ารหัส แต่เพียงแค่กระจายการเชื่อมต่อ TCP ไปยังแต่ละเซิร์ฟเวอร์ ทำให้ยังคงรักษา "การสื่อสารผ่านการเชื่อมต่อ TCP เดียวกัน" ซึ่งเป็นสิ่งที่จำเป็นสำหรับการตรวจสอบสิทธิ์แบบ NTLM ในทำนองเดียวกัน สำหรับ Kerberos มันจะจำลองประสบการณ์ของไคลเอ็นต์ในการเชื่อมต่อโดยตรงกับ FQDN ของ IIS (บริการ) ดังนั้นการตรวจสอบสิทธิ์แบบใช้ตั๋ว (ticket-based authentication) จึงใช้งานได้ตราบใดที่ SPN ถูกกำหนดค่าอย่างถูกต้อง AWS NLB และ Classic LB ในโหมด TCP listener, ตัวกระจายโหลดภายในของ Azure และโหมด L4 ของ F5 จัดอยู่ในประเภทนี้ (อื่นๆ ได้แก่ โหมด TCP ของ HAProxy และ nginx stream) และสามารถข้ามการตรวจสอบสิทธิ์แบบรวมของ Windows ได้

บุญ

เนื่องจากการเชื่อมต่อ TLS ไม่ถูกขัดจังหวะจากฝั่งไคลเอนต์ไปยังฝั่งเซิร์ฟเวอร์โปรโตคอลการตรวจสอบสิทธิ์ของ Windows ยังคงทำหน้าที่ตามที่ตั้งใจไว้ใช่ เป็นไปได้ การจับมือแบบ 3 ทางของ NTLM เสร็จสมบูรณ์ภายในการเชื่อมต่อเดียว และตั๋ว Kerberos จะถูกส่งไปยังเซิร์ฟเวอร์แบ็กเอนด์อย่างถูกต้อง นอกจากนี้ เนื่องจากตัวกระจายโหลดทำงานที่เลเยอร์ 4 จึงมีค่าใช้จ่ายต่ำและคาดหวังได้ว่าจะมีปริมาณงานสูง

ข้อเสีย

ความท้าทายที่ใหญ่ที่สุดในการกำหนดค่าโหลดบาลานเซอร์ L4 คือการไม่สามารถกำหนดเส้นทางแบบละเอียดตามพาธหรือชื่อโฮสต์ได้ ตัวอย่างเช่น พาธ URL (เช่น:/api、/แชทการกระจายคำขอไปยังเซิร์ฟเวอร์แบ็กเอนด์ต่างๆ ขึ้นอยู่กับคำขอ เป็นคุณสมบัติที่สามารถทำได้เฉพาะในเลเยอร์ 7 (HTTP) เท่านั้น และไม่สามารถทำได้ในเลเยอร์ 4 (TCP)

ดังนั้น ขึ้นอยู่กับข้อกำหนดของระบบ อาจจำเป็นต้องเตรียม FQDN หลายรายการและกำหนดเซิร์ฟเวอร์เสมือนที่แตกต่างกัน (เช่น เว็บเซิร์ฟเวอร์และเซิร์ฟเวอร์ตรวจสอบสิทธิ์ Windows) ให้กับตัวกระจายโหลดสำหรับแต่ละวัตถุประสงค์ ซึ่งมีข้อเสียคือทำให้การกำหนดค่ามีความซับซ้อนมากขึ้น

โดยเฉพาะอย่างยิ่ง เมื่อเข้าถึงหน้าการตรวจสอบสิทธิ์ของ Windows โดยใช้ FQDN (Fully Qualified Domain Name) การลงทะเบียน SPN เรื่องนี้ค่อนข้างซับซ้อน ดังนั้นโปรดตรวจสอบข้อมูลต่อไปนี้ด้วย

การประชุมผ่านเว็บ แชท และโปรแกรมส่งข้อความ

การตั้งค่า IIS สำหรับการตรวจสอบสิทธิ์ Windows แบบบูรณาการที่ประสบความสำเร็จในสภาพแวดล้อมโหลดบาลานเซอร์ L4 | การประชุมผ่านเว็บ Chat&Messenger ภาพรวม: บทความต่อไปนี้อธิบายวิธีการกำหนดค่าการตรวจสอบสิทธิ์แบบรวมของ Windows (IWA) ใน IIS ที่มีโหลดบาลานเซอร์ระดับ L4 และสภาพแวดล้อมการยุติ SSL วิธีนี้…

นอกจากนี้ โปรดทราบด้วยว่าการตั้งค่าทั้งหมดต่อไปนี้ที่จำเป็นสำหรับการตรวจสอบสิทธิ์ของ Windows ควรตั้งค่าเป็น FQDN ของโหลดบาลานเซอร์

• แท็บ "ความปลอดภัย" ในตัวเลือกอินเทอร์เน็ตนั้นจำเป็นสำหรับการตรวจสอบสิทธิ์ของ Windows"ไซต์" บน "อินทราเน็ตภายในองค์กร" การตั้งค่า
• การกำหนดค่าการเชื่อมโยงเว็บไซต์ 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、認証成功

③: การยุติ SSL ของโหลดบาลานเซอร์ L7 และการกำหนดค่าการเปลี่ยนเส้นทางไปยัง IIS

ไคลเอ็นต์ ──HTTPS──▶ โหลดบาลานเซอร์ L7 (การยุติ SSL)
LB ── HTTP 302 (การตอบสนองการเปลี่ยนเส้นทาง) → ไคลเอ็นต์
ไคลเอ็นต์ ──HTTPS──▶ IIS (เข้าถึงพอร์ต 443 โดยตรง)

ความพร้อมใช้งาน

การตั้งค่านี้ใช้สำหรับการตรวจสอบสิทธิ์ของ Windowsมีอยู่เป็น.

เหตุผล

แนวคิดคือ ตัว Load Balancer จะไม่ส่งต่อการสื่อสารจริง แต่จะเปลี่ยนเส้นทางการเชื่อมต่อของไคลเอนต์ไปยัง IIS Backend โดยตรงผ่านการตอบสนอง HTTP 302 ในตอนแรก ผู้ใช้จะเข้าถึง URL ของ Load Balancer แต่ Load Balancer ของ L7 จะวิเคราะห์เนื้อหาในขณะที่ทำการยุติ SSL ที่นั่น และส่งการตอบสนอง 302 พร้อมส่วนหัว Location ที่สั่งให้ผู้ใช้เชื่อมต่อผ่าน HTTPS ไปยังที่อยู่ IIS ที่เหมาะสม (เช่น ชื่อโฮสต์หรือที่อยู่ IP ของ IIS แต่ละตัว) เบราว์เซอร์ของไคลเอนต์จะได้รับการเปลี่ยนแปลงเส้นทางนี้และส่งคำขอไปยัง IIS ที่ระบุโดยอัตโนมัติผ่าน HTTPS

ผลลัพธ์,ในการร้องขอครั้งที่สอง ไคลเอนต์และ IIS จะเชื่อมต่อกันโดยตรงผ่าน TLSดังนั้น ข้อมูลการตรวจสอบสิทธิ์ Kerberos/NTLM จึงถูกแลกเปลี่ยนแบบ end-to-end เช่นเดียวกัน เนื่องจากตัว Load Balancer ไม่เข้าไปแทรกแซงในระหว่างกระบวนการตรวจสอบสิทธิ์ ปัญหาการสูญหายของส่วนหัวการตรวจสอบสิทธิ์ที่แสดงในแผนการกำหนดค่า ① จึงสามารถหลีกเลี่ยงได้

บุญ

ข้อดีที่สำคัญอย่างหนึ่งคือ TLS สร้างการเชื่อมต่อโดยตรงจากไคลเอ็นต์ไปยัง IIS ทำให้การตรวจสอบสิทธิ์ของ Windows ง่ายขึ้นมากเป็น.
หากการตรวจสอบสิทธิ์สำเร็จด้วย IIS เพียงอย่างเดียว ก็สามารถใช้การตั้งค่าดังกล่าวได้เลย ดังนั้นการเพิ่มตัวกระจายโหลดจะไม่ทำให้ยากขึ้นแต่อย่างใด

นอกจากนี้ การใช้การเปลี่ยนเส้นทาง (redirects) ยังช่วยให้ตัวจัดการโหลด (load balancer) สามารถควบคุมการกำหนดเส้นทางได้อย่างยืดหยุ่น ตัวอย่างเช่น การเปลี่ยนเส้นทางไปยัง URL ของ IIS ฝั่งเซิร์ฟเวอร์ที่แตกต่างกัน ขึ้นอยู่กับเส้นทางหรือชื่อโฮสต์ของ URL ที่เข้าถึงในตอนเริ่มต้น จะทำให้ได้ผลลัพธ์ที่ใกล้เคียงกับการกระจายตามเส้นทาง หากมีบริการจำนวนมากอยู่ภายใต้ตัวจัดการโหลด ก็สามารถรวมบริการเหล่านั้นเข้าไว้ในจุดเข้าใช้งานทั่วไปบนตัวจัดการโหลด จากนั้นจึงนำผู้ใช้ไปยัง URL จริงของแต่ละบริการ ทำให้ดูเหมือนเป็นหน่วยเดียวบนหน้าจอ

ข้อเสีย

ข้อเสียอย่างหนึ่งคือ IIS ไม่สามารถติดตั้งอยู่ด้านหลังโหลดบาลานเซอร์ได้ จึงต้องออกแบบเอนด์พอยต์แยกต่างหากสำหรับ IIS ในฐานะเซิร์ฟเวอร์สาธารณะ และต้องวางใบรับรองในตำแหน่งที่แตกต่างจากของโหลดบาลานเซอร์

ข้อเสียอีกประการหนึ่งคือจะมีการเปลี่ยนเส้นทางเกิดขึ้นในการเข้าถึงครั้งแรก แต่ในความเป็นจริงแล้ว มันเป็นเพียงการเชื่อมต่อใหม่ทันทีผ่านการตอบสนอง HTTP 302 และผลกระทบต่อประสบการณ์ของผู้ใช้นั้นแทบจะไม่มีเลย

หากต้องการข้อมูลอ้างอิงเกี่ยวกับความเร็วในการเข้าสู่ระบบบริการของเราหลังจากเปลี่ยนเส้นทางไปยัง IIS และการตรวจสอบสิทธิ์ของ Windows โปรดดูที่นี่ภาพยนตร์โปรดดูข้อมูลต่อไปนี้

ตารางเปรียบเทียบของแต่ละการกำหนดค่า

สรุป

เพื่อให้การตรวจสอบสิทธิ์ของ Windows (NTLM/Kerberos) ทำงานได้อย่างถูกต้อง จำเป็นอย่างยิ่งที่จะต้องรักษาการเชื่อมต่อ TLS ให้สม่ำเสมอตั้งแต่ฝั่งไคลเอ็นต์ไปจนถึง IIS

ในการกำหนดค่าโหลดบาลานเซอร์ L4 ของตัวเลือก ② การตรวจสอบสิทธิ์จะสำเร็จเนื่องจากไม่มีการส่งต่อ TLS และทราฟฟิกจะส่งตรงไปยัง IIS อย่างไรก็ตาม การที่ไม่สามารถกำหนดเส้นทางแบบละเอียดได้ และความจำเป็นในการกำหนดค่าเซิร์ฟเวอร์เสมือนหลายตัวภายในโหลดบาลานเซอร์ ทำให้การกำหนดค่าทำได้ยากขึ้น

ในทางกลับกัน การกำหนดค่าการเปลี่ยนเส้นทางในตัวเลือก ③ นั้นเหมาะสมที่สุดจากมุมมองของ TLS และการตรวจสอบสิทธิ์ เนื่องจากจะจัดการคำขอเริ่มต้นด้วยโหลดบาลานเซอร์ L7 จากนั้นจึงเชื่อมต่อโดยตรงกับ IIS ต่อไป การเปลี่ยนเส้นทางเส้นทางเฉพาะไปยัง FQDN ของ IIS ทำให้สามารถควบคุมกฎ L7 และการตรวจสอบสิทธิ์ Windows ได้พร้อมกัน จำเป็นต้องตรวจสอบว่ามีปัญหาเกี่ยวกับนโยบายใดๆ กับ IIS ที่ไม่ได้อยู่เบื้องหลังโหลดบาลานเซอร์หรือไม่ ซึ่งอนุญาตพอร์ต 443 ด้วย ANY

ในทางกลับกัน ในการกำหนดค่าเช่นตัวเลือก ① ซึ่งตัวโหลดบาลานเซอร์ L7 เข้ามาแทรกแซงในการยุติ TLS หรือการตีความ HTTP ข้อมูลการตรวจสอบสิทธิ์จะถูกขัดจังหวะ และการตรวจสอบสิทธิ์ของ Windows จะใช้งานไม่ได้

เราหวังว่าบทความนี้จะเป็นประโยชน์ในการพิจารณาการกำหนดค่าที่สร้างสมดุลระหว่างการกระจายภาระงานและการสื่อสารแบบเข้ารหัส ในขณะที่ยังคงรักษาระบบการตรวจสอบสิทธิ์ที่แข็งแกร่งไว้ได้