Score:0

ฉันจะบังคับให้ Active Directory รวม DNS ให้ส่งคืนระเบียน SRV สำหรับตัวควบคุมโดเมนเฉพาะตามเครือข่ายย่อยของไคลเอนต์ได้อย่างไร

ธง fr

ฉันมีสำนักงานหลายชุดที่เข้าร่วมโดยใช้ IPsec VPN และเครือข่าย MPLS ผสมผสานกัน ไซต์ส่วนใหญ่สร้างการจัดเรียงแบบตาข่ายโดยใช้ VPN แต่ไซต์ B มี IPsec VPN เพียงตัวเดียวไปยังไซต์ A - ไซต์ B ไม่สามารถเข้าถึงไซต์อื่น ๆ ได้ (ไซต์ C และ D)

ไซต์ A, C และ D ทั้งหมดใช้โดเมน Active Directory ร่วมกัน เช่น "companya.com" ตัวควบคุมโดเมนสำหรับ companya.com อยู่ในไซต์ทั้งสามแห่ง และทั้งหมดกำลังเรียกใช้ Windows Server 2012 R2

ไซต์ B ใช้โดเมน Active Directory ของตัวเอง - พูดว่า "companyb.com" ตัวควบคุมโดเมนสำหรับ companyb.com จะอยู่ในไซต์ B เท่านั้น ตัวควบคุมโดเมนหนึ่งรัน Windows Server 2019 และอีกตัวหนึ่งรัน Windows Server 2012 R2

เราได้สร้างความไว้วางใจแบบสองทางระหว่างโดเมน AD companya.com และ companyb.com สิ่งนี้ทำได้โดยใช้ตัวส่งต่อแบบมีเงื่อนไขในเซิร์ฟเวอร์ AD DNS สำหรับ companyb.com ซึ่งชี้ไปที่ตัวควบคุมโดเมนทั้งสองบนไซต์ A สำหรับ companya.com นอกจากนี้ เรายังตั้งค่า stub zone ใน companya.com ให้ชี้ไปที่ตัวควบคุมโดเมนทั้งสองบนไซต์ B สำหรับ companyb.com

ตามที่คาดไว้ ตัวควบคุมโดเมนทั้งสองในไซต์ A สามารถติดต่อตัวควบคุมโดเมนในไซต์ B ได้อย่างน่าเชื่อถือ อย่างไรก็ตาม ตัวควบคุมโดเมนทั้งสองในไซต์ B สามารถติดต่อตัวควบคุมโดเมนในไซต์ A ได้อย่างน่าเชื่อถือเท่านั้น เนื่องจากเราได้ใช้ตัวส่งต่อแบบมีเงื่อนไข บางครั้งการค้นหา DNS สำหรับระเบียน SRV การอธิบายตัวควบคุมโดเมนในไซต์ B ส่งคืนผลลัพธ์สำหรับไซต์ C และ D ซึ่งไซต์ B ไม่สามารถเข้าถึงได้เลย สิ่งนี้ทำให้เกิดข้อผิดพลาดเป็นระยะ ๆ เช่น "ระบบไม่สามารถติดต่อตัวควบคุมโดเมนเพื่อให้บริการคำขอตรวจสอบสิทธิ์ โปรดลองอีกครั้งในภายหลัง"

ฉันต้องแน่ใจว่าเมื่อตัวควบคุมโดเมนใน companyb.com ทำการค้นหาเพื่อค้นหาตัวควบคุมโดเมนบน companya.com นั้นจะส่งกลับเฉพาะตัวควบคุมโดเมนในไซต์ A เท่านั้น

ฉันเหนื่อย:

  • การกำหนดค่าไซต์โฆษณาสำหรับไซต์ B โดยใช้ซับเน็ตที่ตัวควบคุมโดเมน companyb.com เชื่อมต่ออยู่ อย่างไรก็ตาม ฉันคิดว่าวิธีนี้ใช้ไม่ได้เพราะไม่มีการกำหนดค่าใดใน DNS เพื่อระบุว่าไซต์ B ควรได้รับเฉพาะผลลัพธ์สำหรับไซต์ A
  • การแทนที่ Forwarder ที่มีเงื่อนไขบน DC ใน companyb.com ด้วยโซน stub ปัญหาเดิมยังคงอยู่ ยกเว้นแย่ลงเนื่องจากโซนต้นขั้วทำให้เกิดการค้นหาเซิร์ฟเวอร์ DNS ในไซต์ C และ D ซึ่งไม่สามารถเข้าถึงได้
  • เพิ่มโซนหลักที่ผสานรวม AD สำหรับ companya.com บนเซิร์ฟเวอร์ DNS ของ companyb.com ด้วยตนเอง และเพิ่มระเบียนทั้งหมดที่ชี้ไปยังตัวควบคุมโดเมนบนไซต์ A:
    • ระเบียน A หลายรายการสำหรับ companya.com
    • ระเบียน _gc._tcp.companya.com หลายรายการ
    • ระเบียน _ldap._tcp.companya.com หลายรายการ
    • _kerberos._tcp.companya.com หลายรายการ

ฉันไม่สามารถสร้างช่องสัญญาณ IPsec ระหว่างไซต์ B และไซต์ C และ D และฉันก็ไม่สามารถกำหนดเส้นทางการรับส่งข้อมูลไปยังไซต์ C และ D ผ่านอุโมงค์ที่มีอยู่จากไซต์ B ไปยังไซต์ A

ฉันสงสัยว่าฟีเจอร์นโยบาย DNS ของ Windows Server 2016 อาจช่วยสถานการณ์นี้ได้ แต่ฉันไม่มีสิทธิ์เข้าถึง DC ที่ใช้ Windows Server 2016 ฉันยังสงสัยว่าฉันอาจพลาดบันทึกบางอย่างเมื่อฉันตั้งค่าโซน DNS บนเซิร์ฟเวอร์ของ companyb.com ด้วยตนเอง

ข้อมูลเชิงลึกใด ๆ ที่จะได้รับการชื่นชม

cn flag
ดูเหมือนว่าไม่จำเป็นและซับซ้อน กระบวนการ DC Locator ออกแบบมาเพื่อเลือกและทดสอบ DC หากข้อผิดพลาดคือ "ระบบไม่สามารถติดต่อตัวควบคุมโดเมนได้" หมายความว่าไม่มี DC ที่ใช้งานได้ในผลลัพธ์ใดๆ ที่ส่งคืน นอกจากนี้ ไคลเอ็นต์ควรพยายามใช้เรกคอร์ดใดๆ หากไม่มีเรกคอร์ดในไซต์ท้องถิ่นสำหรับโดเมนเป้าหมาย
fr flag
สิ่งใดที่อาจทำให้การเชื่อมต่อขาดช่วงในกรณีนี้ ฉันได้ตรวจสอบ VPN แล้วและสามารถดูทราฟฟิกที่ปลายทางสำหรับตัวควบคุมโดเมนในไซต์ A จากไซต์ B แต่สำหรับบางคำขอเท่านั้น ส่วนอื่นๆ แสดงการรับส่งข้อมูลจากไซต์ B ไปยังไซต์ C และ D และการรับส่งข้อมูลดังกล่าวไม่สามารถกำหนดเส้นทางได้หากไม่มีอุโมงค์ระหว่างเครือข่ายย่อยที่เกี่ยวข้อง
cn flag
อาจมีหลายสาเหตุ จำเป็นต้องมีการจับแพ็กเก็ตที่สัมพันธ์กันเมื่อเกิดอาการเพื่อทราบข้อมูลเพิ่มเติม อาจเป็นได้ว่า DC กำลังผ่านการทดสอบ ping ของ LDAP แต่หยุดทำงาน อาจเป็นการจัดสรรพอร์ตไฟร์วอลล์ที่ไม่ถูกต้องสำหรับกิจกรรม RPC
fr flag
ตามที่แนะนำ ฉันได้ตรวจสอบการจับแพ็กเก็ตแล้ว และเห็นความพยายามอย่างต่อเนื่องในการเชื่อมต่อกับ DC ที่ไม่สามารถเข้าถึงได้ เป็นไปไม่ได้ที่ DC เหล่านี้จะตอบสนองต่อการทดสอบ ping ของ LDAP ตามที่คุณอธิบาย เนื่องจากไม่มีอุโมงค์ VPN ระหว่างไซต์ B และไซต์ C และ D ดังนั้นฉันจึงไม่แน่ใจว่าเหตุใดการรับส่งข้อมูลจึงถูกส่งไปทางนั้น
cn flag
ขึ้นอยู่กับว่า "เชื่อมต่อ" คืออะไรและแอปพลิเคชัน หากเป็นฟังก์ชันดั้งเดิมของ Windows คาดว่าจุดสิ้นสุดจะเชื่อมต่อกับ DC ใดๆ และทั้งหมดและทำการทดสอบ หากเป็นแอปพลิเคชัน (ทำงานผิดปกติ) ที่เชื่อมต่อกับโดเมน FQDN แอปพลิเคชันนั้นจะเชื่อมต่อกับบันทึก DC แรกที่ส่งคืนโดยไม่คำนึงถึงสถานะ นอกจากนี้ หากไซต์ DC ไม่สามารถเข้าถึงได้จากที่อื่น ก็ไม่ควรโฆษณาว่าเป็นไซต์ DC ที่มีให้บริการทั่วโลก นั่นคือสิ่งที่ช่วยในการจำ DNS
fr flag
ฉันเห็น tcp/445 ซึ่งจัดหมวดหมู่ Active Directory จากไซต์ B ถึงไซต์ C และ D แอปพลิเคชันที่เป็นปัญหาคือ Sage กำลังเชื่อมต่อกับ Windows File Share เพื่อค้นหาข้อมูล คุณช่วยอธิบายเพิ่มเติมเกี่ยวกับการช่วยจำ DNS ได้ไหม ความเข้าใจเกี่ยวกับการตั้งค่า DNS ของฉันคือถ้าฉันอยู่ในโดเมนของ companya.com ฉันสามารถกำหนดไซต์ AD เป็น sitea.companya.com จากนั้น หากลูกค้าต้องการค้นหา DCs บนไซต์a พวกเขาสามารถแก้ไข _ldap._tcp.sitea.companya.com สิ่งนี้ทำงานอย่างไรกับความน่าเชื่อถือเนื่องจากความน่าเชื่อถือไม่รู้จักไซต์ในโดเมนอื่น
cn flag
หากเป็นแอปพลิเคชัน ฉันไม่เห็นบันทึก SRV ที่นำมาพิจารณาในเรื่องนี้ หากคุณมีเรกคอร์ด A เหมือนกับเรกคอร์ดพาเรนต์ และไม่สามารถเข้าถึง DC เหล่านั้นได้ สิ่งนี้จะเกิดขึ้นได้ คุณต้องล้างระเบียน A สำหรับโดเมนปัญหาในไซต์ที่เกิดปัญหา หรือเปลี่ยนแอปพลิเคชันให้มีความยืดหยุ่นมากขึ้นและไม่ใช้ระเบียนที่ไม่ทำงาน (ซึ่งไม่น่าจะเป็นไปได้) โซน Stub มีไว้สำหรับการทำงานของ Windows ดั้งเดิมในโดเมนปกติ ไม่ใช่สำหรับการใช้งานแอปพลิเคชันในฟอเรสต์ที่มีการเผยแพร่ระเบียน DNS ที่ไม่ทำงานสำหรับโดเมน

โพสต์คำตอบ

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