เหตุใดจึงต้องใช้ Kerberos แทนที่จะเป็น NTLM ใน IIS

นี่คือสิ่งที่ฉันไม่เคยได้รับคำตอบเช่นเดียวกับที่ฉันชอบ: ข้อได้เปรียบที่แท้จริงของการใช้การพิสูจน์ตัวตน Kerberos ใน IIS แทนที่จะเป็น NTLM คืออะไร

ฉันเคยเห็นผู้คนมากมายต้องดิ้นรนเพื่อตั้งค่า (รวมตัวเอง) และฉันไม่สามารถหาเหตุผลที่ดีในการใช้งานได้ จะต้องมีข้อได้เปรียบที่ค่อนข้างสวย แต่ไม่อย่างนั้นมันจะไม่คุ้มค่ากับปัญหาทั้งหมดในการตั้งค่าใช่ไหม

จากมุมมองของ Windows เท่านั้น:

NTLM

• ทำงานร่วมกับทั้ง ภายนอก (ไม่ใช่โดเมน) และภายในลูกค้า
• ทำงานได้กับทั้งบัญชีโดเมนและบัญชีผู้ใช้ภายในกล่อง IIS
  • ใช้บัญชีโดเมนเฉพาะเซิร์ฟเวอร์เท่านั้นที่ต้องมีการเชื่อมต่อโดยตรงกับตัวควบคุมโดเมน (DC)
  • ใช้บัญชีท้องถิ่นคุณไม่จำเป็นต้องเชื่อมต่อที่ไหนก็ได้ :)
  • คุณไม่จำเป็นต้องเข้าสู่ระบบในฐานะผู้ใช้ที่มีปัญหาในการใช้ข้อมูลประจำตัว
  • นอกเหนือ : ไม่ใช่เรื่องแปลกที่ DC จะถูกครอบงำโดยเซิร์ฟเวอร์ NTLM ที่ไม่ว่าง (IIS, Exchange, TMG / ISA, ฯลฯ ) ที่มีปริมาณการร้องขอ NTLM (เพื่อบรรเทา: MaxConcurrentAPI, AuthPersistSingleRequest(เท็จ) , DC ที่เร็วขึ้น) (ตัวเอง - โบนัสอ้างอิง )
• ต้องการการเชื่อมต่อไคลเอนต์กับเซิร์ฟเวอร์ IIS เท่านั้น (บนพอร์ตไซต์ไม่มีอะไรอื่นเช่นทุกอย่างเกิดขึ้นผ่าน HTTP (หรือ HTTPS))
• สามารถสำรวจพร็อกซีใดก็ได้ที่สนับสนุนHTTP Keep-Alive s
  • คุณอาจใช้ TLS / SSL เพื่อแก้ไขปัญหาอื่น ๆ
• ต้องใช้การเดินทางไปกลับหลายครั้งในการตรวจสอบสิทธิ์ด้วยแพ็คเก็ตขนาดเล็ก
  • (รูปแบบบันทึกคือ 401.2, 401.1, 200พร้อมชื่อผู้ใช้)
• ไม่สามารถใช้ในสถานการณ์ที่จำเป็นต้องมีการตรวจสอบสิทธิ์แบบฮอปสองครั้ง
  • เช่นข้อมูลประจำตัวของผู้ใช้จะถูกส่งต่อไปยังบริการบนคอมพิวเตอร์เครื่องอื่น
• รองรับลูกค้าเก่า (<Win2000)
• อ่อนไหวต่อความคลาดเคลื่อนระดับ LM Auth (ไม่ตรงกันlmcompatibilitylevel)
• ถูกใช้เป็นทางเลือกโดยแพ็คเกจเจรจาหากควบคุมไม่สำเร็จ
  • ( ไม่ใช่ "ถ้าการเข้าถึงถูกปฏิเสธด้วย Curb", Curb จะต้องหยุดให้ NTLM ใช้งาน - โดยปกตินี่จะดูเหมือนว่าไม่ได้รับตั๋วถ้าลูกค้าได้รับตั๋วและมันไม่สมบูรณ์นั่นก็ไม่ได้ทำให้เกิดทางเลือก)

Kerberos

• ทำงานกับไคลเอนต์ที่เข้าร่วมโดเมนในปัจจุบันเท่านั้น
  • ต้องการการเชื่อมต่อไคลเอนต์กับAD DC (tcp / udp 88) และเซิร์ฟเวอร์ (ตั๋วจะถูกดึงจากลูกค้าจาก DC ผ่านทาง Curb port แล้วมอบให้กับเซิร์ฟเวอร์โดยใช้ HTTP)

• อาจจะสามารถที่จะตัดผ่านพร็อกซี แต่เห็นจุดดีซีเหนือ: คุณยังต้องการที่จะอยู่ในเครือข่ายเดียวกันเป็น DC ที่ใช้งานเช่นเดียวกับเซิร์ฟเวอร์

  • ดังนั้นในทางทฤษฎีถ้าคุณมีโดเมนที่ลูกค้าที่เชื่อมต่ออินเทอร์เน็ตพูดคุยโดยตรงกับซีที่เชื่อมต่ออินเทอร์เน็ตก็สามารถทำงานได้ แต่อย่าทำอย่างนั้นถ้าคุณไม่ได้รู้
  • ในสถานการณ์จำลองพร็อกซีย้อนกลับ (ISA / TMG) เซิร์ฟเวอร์การเปลี่ยนแปลงโปรโตคอลต้องอยู่บนเครือข่ายนั่นคือไม่ใช่ไคลเอ็นต์ ... แต่จากนั้นไคลเอ็นต์ไม่ได้เป็นคนหนึ่งที่กำลังทำบิต Kerberos (จำเป็นต้องคิดว่าแบบฟอร์มรับรองความถูกต้องเพื่อลด การเปลี่ยนแปลง)

• ตั๋วยาวอาศัยอยู่ (10h) หมายถึงการสื่อสาร DC น้อยในช่วงชีวิตของตั๋ว - และจะเน้น: นี้สามารถบันทึกหลายพันล้านของการร้องขอ ต่อลูกค้าตลอดชีวิตนั้น - ( AuthPersistNonNTLMยังคงเป็นสิ่งที่; ตรวจสอบ Kerberos PACที่ใช้จะเป็นสิ่งที่)

• ต้องการการตรวจสอบแบบไปกลับครั้งเดียวแต่ขนาดของข้อมูลการรับรองความถูกต้องค่อนข้างใหญ่ (ปกติ 6-16K) ( 401 , {(เข้ารหัส) ขนาดโทเค็น} 200 )
• สามารถใช้กับการมอบหมาย (โปรดจำกัดอยู่เสมอ) เพื่อเปิดใช้งานการรับรองความถูกต้อง Windows ของผู้ใช้ที่เชื่อมต่อกับบริการถัดไป
  • ตัวอย่างเช่นเพื่ออนุญาตให้UserAเข้าถึง IIS และใช้บัญชีผู้ใช้เดียวกันนั้นเมื่อ IIS เข้าถึง SQL Server นี่คือ "การมอบหมายการรับรองความถูกต้อง"
  • ( จำกัดในบริบทนี้หมายถึง "แต่ไม่ใช่อย่างอื่น" เช่น Exchange หรือกล่อง SQL อื่น)
• ปัจจุบันเป็นแพคเกจความปลอดภัยหลักสำหรับการรับรองความถูกต้องเจรจา
  • หมายถึงสมาชิกโดเมน Windows ต้องการเมื่อพวกเขาได้รับ
• ต้องลงทะเบียน SPNซึ่งอาจยุ่งยาก กฎระเบียบช่วยเหลือว่า
• ต้องใช้ชื่อเป็นเป้าหมายไม่ใช่ที่อยู่ IP
• เหตุผลระงับอาจล้มเหลว:
  • ใช้ที่อยู่ IP แทนชื่อ
  • ไม่ได้ลงทะเบียน SPN
  • ลงทะเบียน SPN ซ้ำแล้ว
  • SPN ลงทะเบียนกับบัญชีที่ไม่ถูกต้อง ( KRB_ERR_AP_MODIFIED)
  • ไม่มีการเชื่อมต่อ DNS / DC ของไคลเอ็นต์
  • การตั้งค่าพร็อกซีไคลเอนต์ / Local Intranet Zone ไม่ได้ใช้สำหรับไซต์เป้าหมาย

ในขณะที่เราอยู่ที่:

ขั้นพื้นฐาน

• สามารถ multi-hop แต่ทำได้โดยเปิดเผยชื่อผู้ใช้และรหัสผ่านของคุณโดยตรงไปยังเว็บแอปเป้าหมาย
  • ซึ่งสามารถทำอะไรก็ได้ตามที่ต้องการกับพวกเขา สิ่งใด
  • "โอ้ผู้ดูแลระบบโดเมนเพิ่งใช้แอพของฉันหรือไม่และฉันเพิ่งอ่านอีเมลของพวกเขาหรือไม่จากนั้นรีเซ็ตรหัสผ่านหรือไม่Awww. สงสาร "
• ต้องการความปลอดภัยของเลเยอร์การขนส่ง (เช่น TLS / SSL) สำหรับรูปแบบความปลอดภัยใด ๆ
  • จากนั้นดูปัญหาก่อนหน้า
• ทำงานกับเบราว์เซอร์ใด ๆ
  • (แต่ดูปัญหาแรก )
• ต้องใช้การเดินทางไป - กลับครั้งเดียวในการตรวจสอบสิทธิ์ ( 401 , 200 )
• สามารถใช้ในสถานการณ์แบบ multi-hop ได้เนื่องจาก Windows สามารถทำการเข้าสู่ระบบแบบโต้ตอบด้วยข้อมูลประจำตัวพื้นฐาน
  • อาจจำเป็นต้องLogonTypeมีการกำหนดค่าให้ทำสิ่งนี้ให้สำเร็จ (คิดว่าค่าเริ่มต้นเปลี่ยนเป็น cleartext เครือข่ายระหว่างปี 2000 ถึง 2003 แต่อาจจะ misremembering)
  • แต่อีกครั้ง , ดูประเด็นแรก
  • ได้รับความประทับใจว่าปัญหาแรกนั้นสำคัญจริงๆหรือ มันคือ.

เพื่อสรุป:

การควบคุมอาจเป็นเรื่องยุ่งยากในการตั้งค่า แต่มีคำแนะนำมากมาย ( ของฉัน ) ออกมีที่พยายามลดความซับซ้อนของกระบวนการและเครื่องมือที่มีการปรับปรุงอย่างมากมายจาก 2003-2008 ( SetSPNสามารถค้นหาซ้ำซึ่งเป็นปัญหาที่พบบ่อยที่สุด ; การใช้งานSETSPN -Sทุกที่ทุกเวลาที่คุณเห็นคำแนะนำการใช้ -A และชีวิตจะมีความสุข)

การมอบข้อ จำกัด มีค่าใช้จ่ายในการเข้าศึกษา

• Kerberos มีชื่อเสียงว่าเป็นกลไกการพิสูจน์ตัวตนที่รวดเร็วและปลอดภัยกว่า NTLM
• ในอดีตยังง่ายต่อการเชื่อมต่อผ่านพร็อกซีเซิร์ฟเวอร์มากกว่า NTLM เนื่องจากลักษณะการเชื่อมต่อของ NTLM
• ดังที่คุณได้กล่าวไว้ Kerberos นั้นยากต่อการเริ่มต้นใช้งานและต้องการการเชื่อมต่อกับโฆษณาที่ไม่สามารถนำไปใช้ได้จริงเสมอไป

อีกวิธีหนึ่งคือการตั้งค่าการรับรองความถูกต้องnegotiateและใช้ทั้งสองอย่างมากกว่าหนึ่งแทนที่จะเป็นวิธีอื่น

จากMicrosoft Application Verifierซึ่งตรวจจับข้อผิดพลาดทั่วไปของนักพัฒนา หนึ่งในข้อผิดพลาดเหล่านั้นคือการใช้ NTLM :

NTLM เป็นโปรโตคอลการตรวจสอบที่ล้าสมัยซึ่งมีข้อบกพร่องซึ่งอาจส่งผลต่อความปลอดภัยของแอปพลิเคชันและระบบปฏิบัติการ ข้อบกพร่องที่สำคัญที่สุดคือการขาดการรับรองความถูกต้องของเซิร์ฟเวอร์ซึ่งอาจทำให้ผู้โจมตีหลอกให้ผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์ที่ถูกหลอก แอพพลิเคชั่นที่ใช้ NTLM อาจมีความเสี่ยงต่อการโจมตีประเภทหนึ่งที่เรียกว่า“ การสะท้อน” หลังนี้ช่วยให้ผู้โจมตีจี้การสนทนาการตรวจสอบความถูกต้องของผู้ใช้ไปยังเซิร์ฟเวอร์ที่ถูกกฎหมายและใช้เพื่อตรวจสอบสิทธิ์ผู้โจมตีไปยังคอมพิวเตอร์ของผู้ใช้ ช่องโหว่และวิธีการใช้ประโยชน์ของ NTLM เป็นเป้าหมายของการเพิ่มกิจกรรมการวิจัยในชุมชนความปลอดภัย

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

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

คุณควรเพิ่มจุดสำคัญมาก:

Kerberos ได้รับมาตรฐานและโปรโตคอลแบบเปิดใน Unix มากว่า 20 ปีในขณะที่ NTLM เป็นโซลูชันที่เป็นกรรมสิทธิ์ของ Microsoft และเป็นที่รู้จักเฉพาะ Microsoft เท่านั้น

ต้องใช้ Kerberos หากคุณต้องการเลียนแบบผู้ใช้เพื่อเข้าถึงทรัพยากรที่ไม่ได้อยู่บนเซิร์ฟเวอร์ iis