เหตุใดตัวเลือก MS GPO จึงแบ่งการแชร์ SMB ที่ใช้ไฟล์โฮสต์เป็นชื่อเครื่อง

ไม่เกี่ยวกับไฟล์ 'hosts' â มันทำลายการแบ่งปันที่เข้าถึงได้ ชื่อโฮสต์ที่แตกต่างจากชื่อ "จริง" ของเซิร์ฟเวอร์ ผลลัพธ์ของคุณเป็นเรื่องปกติ เนื่องจากนั่นคือจุดประสงค์ทั้งหมดของ GPO

GPO ที่เป็นปัญหานั้นเหมือนกับการบังคับใช้ TLS SNI ที่พบในเว็บเซิร์ฟเวอร์บางตัว: ไคลเอนต์ระบุว่า "ฉันมาที่นี่เพื่อคุยกับเซิร์ฟเวอร์ SRV01.EXAMPLE.COM" และหากเซิร์ฟเวอร์ไม่รู้จักชื่อนั้นเป็นหนึ่งใน vhosts มันทำหน้าที่ปฏิเสธลูกค้าโดยสิ้นเชิง ดังนั้น หากไคลเอ็นต์ระบุว่าต้องการพูดคุยกับหนึ่งในนามแฝง /etc/hosts ของคุณ แต่เซิร์ฟเวอร์ไม่รู้จักนามแฝง เซิร์ฟเวอร์จะปฏิเสธไคลเอ็นต์

Kerberos มีการบังคับใช้ที่คล้ายกันในตัวอยู่แล้ว (นั่นคือเหตุผลที่คุณต้องลงทะเบียน SPN สำหรับนามแฝงโดยใช้ ชุด) แต่ GPO ทำให้เข้มงวดขึ้น และ ขยายการป้องกันเดียวกันไปยัง NTLM ด้วย

(ดังที่กล่าวไว้แล้วในหน้าเอกสาร สิ่งนี้ควรจะป้องกันการโจมตีการส่งต่อ NTLM โดยที่เซิร์ฟเวอร์ที่เป็นอันตราย A ยอมรับการตรวจสอบสิทธิ์ NTLM จากนั้นส่งต่อแพ็กเก็ต NTLM เดียวกันไปยังเซิร์ฟเวอร์ B จริง – การโจมตีจะป้องกันได้เนื่องจากเซิร์ฟเวอร์ B จะ ดู "ฉันต้องการคุยกับเซิร์ฟเวอร์ A" จากไคลเอนต์)

มัน เป็น เป็นไปได้ที่จะใช้นามแฝงของโฮสต์ แต่ต้องใช้ปุ่มรีจิสตรีจำนวนมากขึ้นเรื่อย ๆ วิธีใช้อย่างเป็นทางการคือ ชื่อคอมพิวเตอร์ netdom REALHOST /add:THEALIAS เช่นเดียวกับใน โพสต์ TechNet นี้และฉันพบบล็อกโพสต์ที่อ้างว่าเพียงพอที่จะทำให้นามแฝงใช้งานได้แม้ว่าจะมีการตรวจสอบความถูกต้องของ SPN ที่เข้มงวด แต่ดูเหมือนว่าจะเป็นจริง ไม่ ค่อนข้างเพียงพอ â มีค่ารีจิสตรีอย่างน้อยหนึ่งค่าถ้าไม่ใช่สองค่าที่ลืมสัมผัส

1. NETDOM ลงทะเบียน เคอร์เบรอส SPNs สำหรับนามแฝงใน AD ทำให้สามารถรับตั๋ว Kerberos ได้ คล้ายกับการออกคำสั่งสองคำสั่งนี้ด้วยตนเอง:

   setspn -S โฮสต์/THEALIAS REALHOST$
   setspn -S HOST/thealias.example.com REALHOST$
   

   สิ่งนี้จำเป็นสำหรับ Kerberos และไม่มีข้อแก้ตัวใดๆ ที่จะไม่ใช้ Kerberos ในสภาพแวดล้อม AD ดังนั้น ไม่ว่าคุณจะเลือกใช้ NETDOM หรือดำเนินการด้วยตนเอง คุณก็ควรลงทะเบียน SPN นามแฝงอยู่ดี

   (ในทางเทคนิคแล้ว SMB ใช้หลักการ "cifs/" แต่ใน AD จะแสดงโดยปริยายทุกครั้งที่มีการลงทะเบียน SPN "host/")

2. จากนั้น NETDOM จะเพิ่มนามแฝงในสองตำแหน่งในรีจิสทรีของเซิร์ฟเวอร์ ทำให้เซิร์ฟเวอร์ลงทะเบียนชื่อเพิ่มเติมใน AD DNS และประกาศผ่าน NetBIOS Browser:

   • เส้นทาง: HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
     ชื่อ: ชื่อคอมพิวเตอร์สำรอง
     ประเภท: REG_MULTI_SZ
     ข้อมูล: {thealias.example.com}

   • เส้นทาง: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
     ชื่อ: ชื่อทางเลือก
     ประเภท: REG_MULTI_SZ
     ข้อมูล: {เธียเลียส}

   ดูเหมือนว่าจะไม่มีผลใดๆ ต่อการตรวจสอบสิทธิ์ (แม้แต่ Kerberos) ดังนั้นฉันเชื่อว่าทั้งสองอย่างนี้เป็นทางเลือกโดยสมบูรณ์หากคุณใช้ /etc/hosts หรือสร้างระเบียน CNAME ด้วยตนเองใน DNS

3. อีกหนึ่งพารามิเตอร์เพิ่มเติมที่ NETDOM ไม่ สร้าง แต่ฉันพบว่าจำเป็นสำหรับการเข้าถึงนามแฝงจากภายในเซิร์ฟเวอร์คือ:

   • เส้นทาง: HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
     ชื่อ: BackConnectionHostName
     ประเภท: REG_MULTI_SZ
     ข้อมูล: {thealias.example.com}

   อันนี้จำเป็นสำหรับการเชื่อมต่อแบบ "วนกลับ" เท่านั้น ดังนั้นโดยทั่วไปอาจไม่จำเป็นอย่างเคร่งครัด แต่อย่างน้อยในกรณีของฉัน เซิร์ฟเวอร์ ทำ ต้องเชื่อมต่อกับนามแฝงของตัวเอง ดังนั้นการตั้งค่าจึงเป็นสิ่งจำเป็น

4. สุดท้าย ฉันพบว่าคุณสมบัติ "การตรวจสอบชื่อเป้าหมาย SPN" มี ของมันเอง รายชื่อที่อนุญาตซึ่งต้องอัปเดตด้วยตนเอง มิฉะนั้น นามแฝงจะถูกปฏิเสธเนื่องจากการตรวจสอบความถูกต้องของ SPN ที่เข้มงวด แม้ว่าจะมีการตั้งค่าข้างต้นทั้งหมดอยู่ก็ตาม:

   • เส้นทาง: HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
     ชื่อ: Srvอนุญาตชื่อเซิร์ฟเวอร์
     ประเภท: REG_MULTI_SZ
     ข้อมูล: {เธียเลียส, thealias.example.com}

   คุณจะต้องแสดงทั้งชื่อย่อ และ FQDN ของทุกนามแฝง â จากการทดลองของฉัน การแสดงรายการหนึ่งไม่ได้บ่งบอกถึงอีกอันหนึ่งโดยอัตโนมัติ

ด้วย Kerberos SPN ที่ลงทะเบียนและ Srvอนุญาตชื่อเซิร์ฟเวอร์ ค่ารีจิสตรีที่ตั้งค่าไว้ นามแฝงควรทำงานได้อย่างถูกต้องแม้ว่าจะมีการตรวจสอบเป้าหมายที่เข้มงวดก็ตาม