วิธีการกำหนดค่าการรับรองความถูกต้องของ Windows แบบรวมของ IIS เพื่อให้ประสบความสำเร็จในสภาพแวดล้อมสมดุลการโหลด + SSL

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

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

ซึ่งช่วยให้ผู้ใช้สามารถเข้าถึงแอปพลิเคชันเว็บที่โฮสต์ (หรือเชื่อมโยง) โดย 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 หรือไม่ เหตุผลทางเทคนิค และข้อดีข้อเสียของการกำหนดค่าแต่ละแบบ

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

①: การยุติ SSL ของตัวปรับสมดุลโหลด L7 + IIS (80 หรือ 443)

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

ความพร้อมจำหน่าย

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

เหตุผล

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

ในความเป็นจริง แม้แต่ในสภาพแวดล้อม AWS การตรวจสอบสิทธิ์ของ Windows ก็ไม่ทำงานกับ Application Load Balancer (ALB) หรือตัวรับฟัง HTTP และต้องใช้ LB ระดับ TCP เช่น Network Load Balancer (NLB)อ้างอิง- นอกจากนี้ Azure Application Gateway v2 ไม่รองรับการส่งส่วนหัว HTTP รวมถึงการตรวจสอบสิทธิ์แบบผสานรวมไปยังแบ็กเอนด์อ้างอิง-

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

②: ตัวปรับสมดุลการโหลด L4 (การส่งผ่าน TLS)

ไคลเอนต์ ──HTTPS──▶ ตัวปรับสมดุลโหลด L4 (การส่งผ่าน TLS) ──HTTPS──▶ IIS (443)

ความพร้อมจำหน่าย

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

เหตุผล

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

บุญ

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

โทษ

ความท้าทายที่ใหญ่ที่สุดในการกำหนดค่าตัวปรับสมดุลการโหลด L4 คือการไม่สามารถดำเนินการกำหนดเส้นทางตามเส้นทางหรือตามชื่อโฮสต์โดยละเอียดได้ ตัวอย่างเช่นในเส้นทาง URL (เช่น/เอพี,/แชทการแจกจ่ายคำขอแต่ละรายการ (หรือหลายคำขอ) ไปยังเซิร์ฟเวอร์แบ็กเอนด์ที่แตกต่างกันเป็นฟีเจอร์ที่สามารถทำได้ด้วย L7 (HTTP) เท่านั้นและไม่สามารถทำได้ด้วย L4 (TCP)

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

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

• จำเป็นต้องมีการรับรองความถูกต้องของ Windows ในแท็บ "ความปลอดภัย" ของตัวเลือกอินเทอร์เน็ต“อินทราเน็ตท้องถิ่น” “ไซต์” การตั้งค่า
• เมื่อเข้าถึงหน้าการตรวจสอบสิทธิ์ของ Windows โดยใช้ FQDN (ชื่อโดเมนที่มีคุณสมบัติครบถ้วน) การลงทะเบียน SPN
• ใบรับรอง SSL ในการตั้งค่าการผูกไซต์ IIS

* หาก 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 + การกำหนดค่าการเปลี่ยนเส้นทาง

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

ความพร้อมจำหน่าย

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

เหตุผล

แนวคิดก็คือตัวปรับสมดุลการโหลดจะไม่ถ่ายทอดการสื่อสารจริง แต่จะเปลี่ยนเส้นทางไคลเอนต์ไปยัง IIS แบ็กเอนด์โดยตรง (การตอบสนอง HTTP 302) เมื่อผู้ใช้เข้าถึง URL ของ LB เป็นครั้งแรก ตัวปรับสมดุลการโหลด L7 จะยุติ SSL ที่นั่น วิเคราะห์เนื้อหา และส่งคืนการตอบสนอง 302 พร้อมกับส่วนหัวตำแหน่งเพื่อเชื่อมต่อกับที่อยู่ IIS ที่เหมาะสม (เช่น ชื่อโฮสต์แต่ละรายการหรือที่อยู่ IP สำหรับแต่ละ IIS) ผ่านทาง HTTPS เบราว์เซอร์ไคลเอนต์จะได้รับการเปลี่ยนเส้นทางนี้และส่งคำขอใหม่อีกครั้งโดยอัตโนมัติผ่าน 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) ทำงานได้อย่างถูกต้อง จำเป็นต้องมีการรักษาเซสชัน TLS ไว้ตลอดตั้งแต่ไคลเอนต์ไปจนถึง IIS

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

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

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

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