คำแนะนำเกี่ยวกับการออกแบบ Active Directory สำหรับเซิร์ฟเวอร์ที่มีหลายหน้า


10

ฉันได้รับมอบหมายจากลูกค้าให้ออกแบบ Active Directory ที่ใช้งานได้สำหรับสถานการณ์ที่มีข้อกำหนดดังต่อไปนี้ (ง่ายกว่าพวกเขาแย่กว่านั้นมาก)

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

ไม่จำเป็นต้องพูดว่าสิ่งนี้ไม่ได้ผลดีกับวิธีการที่ Active Directory ใช้ DNS เพื่อค้นหาตัวควบคุมโดเมน แนวทางที่เป็นไปได้ใด ๆ จะนำไปสู่หนึ่งในสถานการณ์สมมติต่อไปนี้:

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

แน่นอนว่าข้อกำหนดเหล่านี้บ้าไปอย่างสิ้นเชิงและทุกคนไม่สามารถพึงพอใจได้ในเวลาเดียวกันเว้นแต่ใช้วิธีการแก้ปัญหาอย่างบ้าคลั่งเช่นการแยกบริการ DNS บนเครือข่ายสองเครือข่ายและสร้างระเบียน SRV ด้วยมือ (argh) หรือเซิร์ฟเวอร์กำหนด DCs ที่ใช้ DNS และไคลเอ็นต์ค้นหา DCs โดยใช้ WINS (double-argh)

วิธีแก้ปัญหาที่ฉันเกิดขึ้นคือการมี DC สองเครื่องบนเครือข่าย "เซิร์ฟเวอร์" และสอง DC ในหนึ่ง "ไคลเอนต์" หนึ่งกำหนดไซต์โฆษณาสองแห่งและข้ามขอบเขตระหว่างเครือข่ายสองเครือข่ายที่มีปริมาณการจำลองแบบ DC เท่านั้น สิ่งนี้จะยังคงต้องมีการ mangling DNS เนื่องจากแต่ละเซิร์ฟเวอร์ยังคงมีการ์ดเครือข่ายสองใบ (นอกเหนือจาก DCs ฝั่งเซิร์ฟเวอร์สองเครื่องและเซิร์ฟเวอร์ back-end ล้วนๆ) แต่อย่างน้อยก็มีโอกาสที่จะทำงานได้

มีคำแนะนำอื่นใดนอกเหนือจากการหลบหนีให้เร็วที่สุดเท่าที่จะทำได้หรือไม่?


7
หนีเร็วขึ้น ... ถ้าคุณทำได้ ...
— SpacemanSpiff

1
ฉันคิดว่าไม่มีเหตุผลที่คุณไม่สามารถตั้งค่าสองโดเมนแล้วรวมเข้ากับต้นไม้ / ป่าไม้และเรียกมันต่อวัน จากนั้นคุณสามารถใช้เนื้อหาในตัวเพื่อจัดการปัญหาส่วนใหญ่ ถึงกระนั้นใครบางคนก็ต้องตบโง่ออกไป นี่คือวิธีการสร้างเครือข่าย
— Satanicpuppy

1
คนเหล่านี้ไม่เคยได้ยินการกำหนดเส้นทางหรือไม่? "MORE NICS !! 1" ไม่มีการรักษาความปลอดภัยเครือข่าย ที่กล่าวว่าการแบ่ง DNS กับระเบียน SRV แบบแมนนวลนั้นไม่น่ารังเกียจอย่างยิ่ง
— เชนแมดเดน

2
ลูกค้าของคุณไม่เข้าใจการปฏิบัติจริงอย่างชัดเจน ฉันแนะนำให้เรียกเก็บเงินเป็นประจำและมากที่สุดหากคุณไม่สามารถหนีไปได้
— Evan Anderson

1
ไล่ลูกค้าออก
— gWaldo

คำตอบ:


5

ผมขอเริ่มด้วยการบอกว่าผมเห็นด้วยกับคนอื่น ๆ ไม่ว่าจะเป็นการโน้มน้าวใจลูกค้าหรือทำงาน

อย่างไรก็ตามตามข้อกำหนดที่ระบุไว้ของคุณ (มีหลายรายการที่ไม่แสดง) ฉันสามารถคิดถึง (และทดสอบบางส่วน) อย่างน้อยก็เป็นรากฐานสำหรับการทำให้สิ่งนี้เกิดขึ้น

มีลักษณะเฉพาะหลายประการที่ต้องพิจารณา

  1. การจำลองแบบบริการโดเมนไดเรกทอรีที่ใช้งานอยู่
  2. DC Locator กระบวนการของลูกค้า / เซิร์ฟเวอร์สมาชิก
  3. การระบุชื่อและปริมาณข้อมูลสำหรับบริการที่ไม่ใช่ AD DS

หนึ่งและสองมีจำนวนมากที่เหมือนกัน - โดยทั่วไปเราอยู่ในความตั้งใจของ Microsoft ในเรื่องนี้และต้องทำงานภายในขอบเขตของกระบวนการ AD DS ของ Microsoft

ข้อที่สามเรามีที่ว่างนิดหน่อยเพื่อทำงานด้วย เราสามารถเลือกป้ายกำกับที่ใช้สำหรับการเข้าถึงบริการ (ไฟล์อินสแตนซ์ฐานข้อมูล ฯลฯ )

นี่คือสิ่งที่ฉันเสนอ:

สร้างตัวควบคุมโดเมนของคุณ (DC)

  • มีแนวโน้มอย่างน้อยสองคน
  • DC แต่ละอันจะมี NIC สองแห่งหนึ่งแห่งในแต่ละเครือข่าย IP / AD DS ไซต์ - เรียกพวกเขาว่า clt และ srv ในตอนนี้
  • เพียงกำหนดค่า NIC ในแต่ละซีในขณะนี้อยู่ในเครือข่าย srv

กำหนดค่าไซต์ AD และบริการอย่างเหมาะสม

  • srv site และ subnet
  • ไซต์ clt และ subnet
  • ยกเลิกการเลือก "เชื่อมโยงทุกไซต์" จาก Sites -> Inter-site Transports -> คลิกขวาที่ "IP"
  • ลบ DEFAULTIPSITELINK หากมีอยู่ (หรือหากคุณเปลี่ยนชื่อ) ดังนั้นจึงไม่มีการกำหนดค่าลิงก์ของไซต์ โปรดทราบว่านี่เป็นสิ่งที่ไม่รู้จักสำหรับฉัน - KCC อาจเกิดข้อผิดพลาดในการถ่ายโอนข้อมูลลงในบันทึกเหตุการณ์ของบริการไดเรกทอรีที่บอกว่าทั้งสองไซต์ (srv และ clt) ไม่ได้เชื่อมต่อตามช่วงเวลาที่แตกต่างกัน อย่างไรก็ตามการจำลองแบบจะยังคงดำเนินต่อไประหว่าง DC ทั้งสองเนื่องจากพวกเขาสามารถติดต่อกันโดยใช้ IP ในเว็บไซต์เดียวกัน

กำหนดค่าโซนเพิ่มเติมใน AD DS Integrated DNS

  • หากโดเมน AD DS ของคุณเป็นacme.localสร้างสองโฆษณาหลักบูรณาการโซนที่มีการปรับปรุงแบบไดนามิกทำงานที่เรียกว่าclt.acme.local

กำหนดค่า NIC ที่สองใน DC ของคุณ

  • NIC เหล่านี้จะเป็น NIC ในเครือข่าย / ไซต์ clt
  • ตั้งค่า IP ของพวกเขา
  • นี่คือส่วนมหัศจรรย์ - คุณสมบัติอะแดปเตอร์ -> คุณสมบัติ IPv4 -> ขั้นสูง -> แท็บ DNS -> ตั้งค่าส่วนต่อท้าย DNS สำหรับการเชื่อมต่อนี้เป็น clt.acme.local -> ตรวจสอบลงทะเบียนการเชื่อมต่อนี้ ... -> ตรวจสอบใช้การเชื่อมต่อนี้ ส่วนต่อท้าย DNS ... -> ตกลงไปตลอดทาง
  • ipconfig / registerdns
  • สิ่งนี้จะลงทะเบียน clt NIC IP ในโซน clt.acme.local - ให้วิธีการสำหรับเราในการควบคุมว่าจะใช้ IP / เครือข่ายใดในภายหลัง

กำหนดค่าเซิร์ฟเวอร์สมาชิกของ NIC

  • NIC ของเซิร์ฟเวอร์สมาชิกในไซต์ clt จะต้องมีส่วนต่อท้าย DNS และช่องทำเครื่องหมายตั้งตามเช่นเดียวกับด้านบน
  • การตั้งค่าเหล่านี้สามารถใช้กับแบบคงที่และ DHCP ได้ไม่สำคัญ

กำหนดค่า DNS [stub] ตัวแก้ไขพฤติกรรมในไซต์

  • DC's -> กำหนดค่า DC srv NIC เพื่อใช้ตัวเองและ DC srv NIC IP อื่น ๆ ปล่อย DC clt NIC DNS ว่างไว้ (จำเป็นต้องใช้ IP แบบคงที่) (เซิร์ฟเวอร์ DC DNS จะยังคงรับฟัง IP ทั้งหมดตามค่าเริ่มต้น)
  • เซิร์ฟเวอร์สมาชิก -> กำหนดค่าเซิร์ฟเวอร์สมาชิก srv NIC เพื่อใช้ IP ของไซต์ DC srv ปล่อยให้เซิร์ฟเวอร์สมาชิก clt NIC DNS ว่างเปล่า (สามารถใช้ IP แบบคงที่ได้)
  • ลูกค้า / เวิร์กสเตชัน -> กำหนดค่า DNS (ผ่าน DHCP หรือคงที่) เพื่อใช้ clt NIC IP ของ DC

กำหนดค่าการแมป / ทรัพยากรอย่างเหมาะสม

  • เมื่อเซิร์ฟเวอร์คุยกันต้องใช้. acme.local -> จะแก้ปัญหากับ srv network IP
  • เมื่อไคลเอนต์พูดคุยกับเซิร์ฟเวอร์โปรดใช้. clt.acme.local -> จะแก้ปัญหา clt เครือข่าย IP

ฉันกำลังพูดถึงอะไร

  • การจำลองแบบ AD DS จะยังคงเกิดขึ้นเนื่องจาก DC สามารถแก้ไขซึ่งกันและกันและเชื่อมต่อซึ่งกันและกัน โซน acme.local และ _msdcs.acme.local จะมีเฉพาะการจำลอง AD DS ของ DC srv NIC IP จะเกิดขึ้นในเครือข่าย srv เท่านั้น
  • กระบวนการ DC locator สำหรับเซิร์ฟเวอร์สมาชิกและเวิร์คสเตชั่นจะทำงาน - แม้ว่าจะมีความเป็นไปได้ที่จะเกิดความล่าช้าในส่วนต่าง ๆ ของกระบวนการ AD DS ต่าง ๆ เมื่อไม่ทราบไซต์หากมีการส่งคืน DC IP หลายรายการพวกเขาจะพยายาม จนกว่าจะมีใครทำงาน ผลกระทบต่อ DFS-N ยังไม่ได้รับการประเมินอย่างสมบูรณ์ - แต่จะยังคงใช้งานได้
  • บริการ AD AD ที่ไม่ใช่บริการจะทำงานได้ดีหากคุณใช้ป้ายกำกับ. acme.local และ. clt.acme.local ข้างต้นดังที่อธิบายไว้

ฉันยังไม่ได้ทดสอบอย่างสมบูรณ์เนื่องจากค่อนข้างน่าหัวเราะ อย่างไรก็ตามประเด็นของคำตอบ (ว้าวยาว) นี้คือการเริ่มต้นการประเมินว่าเป็นไปได้หรือไม่ - ไม่ควรทำหรือไม่

@Comments

@Massimo 1/2 อย่าสับสนไซต์ AD DS หลายรายการในโซน acme.local และทำให้ SRV บันทึกข้อมูลโดย DC ในไซต์เหล่านั้นในโซน acme.local ด้วยการต้องการบันทึก SRV ในโซน clt.acme.local ส่วนต่อท้าย DNS หลักของลูกค้า (และโดเมน Windows ที่เข้าร่วม) จะยังคงเป็น acme.local ไคลเอ็นต์ / เวิร์กสเตชันมี NIC เดียวโดยมีส่วนต่อท้าย DNS หลักน่าจะได้มาจาก DHCP ตั้งเป็น acme.local

โซน clt.acme.local ไม่จำเป็นต้องมีระเบียน SRV เนื่องจากจะไม่ใช้ในกระบวนการตัวระบุตำแหน่ง DC ไคลเอ็นต์ / เวิร์กสเตชันใช้เพื่อเชื่อมต่อกับบริการที่ไม่ใช่โฆษณา DS ของเซิร์ฟเวอร์สมาชิกโดยใช้ IP ของเซิร์ฟเวอร์สมาชิกในเครือข่าย clt กระบวนการที่เกี่ยวข้องกับ AD DS (ตัวระบุตำแหน่ง DC) จะไม่ใช้ clt.acme.local zone แต่ AD DS sites (และ subnets) ใน acme.local zone

@Massimo 3

จะมีเรคคอร์ด SRV สำหรับทั้งไซต์ clt และ srv AD DS ซึ่งจะมีอยู่ในโซน acme.local - ดูหมายเหตุด้านบน โซน clt.acme.local ไม่จำเป็นต้องมีระเบียน SRV DC ที่เกี่ยวข้อง

ลูกค้าจะสามารถค้นหาการปรับ DC เซิร์ฟเวอร์ DNS ไคลเอนต์ชี้ไปที่ clt IP ของ DC's

เมื่อกระบวนการตัวระบุตำแหน่ง DC บนไคลเอนต์เริ่มทำงาน

  • หากลูกค้าทราบไซต์ของตนคำถาม DNS จะเป็น _ldap._tcp [site] ._ sites.dc._msdcs.acme.local SRV สิ่งนี้จะส่งคืน DC ที่เฉพาะเจาะจงของไซต์ที่มีการบันทึก SRV
  • หากไคลเอนต์ไม่ทราบไซต์ของตนคำถาม DNS จะเป็น _ldap._tcp.dc._msdcs.acme.local SRV นี่จะคืนกลับ DC ทั้งหมด ไคลเอ็นต์จะพยายามผูกกับ LDAP ของ DC จนกว่าจะพบหนึ่งรายการที่ตอบสนอง เมื่อลูกค้าพบหนึ่งมันทำการค้นหาเว็บไซต์เพื่อตรวจสอบเว็บไซต์ของลูกค้าและแคชของเว็บไซต์ในรีจิสทรีเพื่อให้อินสแตนซ์ของ DC locator ในอนาคตเกิดขึ้นเร็วขึ้น

@Massimo 4

เอ่อจับได้ดี วิธีที่ฉันเห็นมันมีสองวิธีแก้ไขปัญหานี้

  1. ผลกระทบที่น้อยกว่า (เทียบกับ 2 ด้านล่าง) คือการสร้างรายการในไฟล์โฮสต์บนไคลเอนต์ / เวิร์กสเตชันสำหรับ dc1.acme.local และ dc2.acme.local ชี้ไปที่ clt NIC IP ของ DC

หรือ

  1. สร้างระเบียน SRV ที่จำเป็นด้วยตนเองในไฟล์ netlogon.dns ใน DC แต่ละรายการ สิ่งนี้น่าจะมีผลกระทบบางอย่างในเครือข่ายเซิร์ฟเวอร์ เซิร์ฟเวอร์สมาชิกอาจสื่อสารกับ DC ของเครือข่าย clt ในบางครั้งหากมีการกำหนดค่านี้

สรุปแล้วมันไม่ได้สวย แต่ก็ไม่จำเป็นต้องเป็นเป้าหมายสุดท้าย บางทีลูกค้ากำลังทดสอบเทคโนโลยีของคุณ วางลงบนโต๊ะประชุมของพวกเขาแล้วบอกพวกเขาว่า "ที่นี่จะทำงานได้ แต่ฉันกำลังชาร์จให้คุณอัตราปกติ 4 เท่าของฉันเพื่อกำหนดค่าและสนับสนุนคุณสามารถลดลงเหลือ 1.5 เท่าของอัตราปกติของฉัน - .5x PITA [วิธีแก้ไขที่ถูกต้อง] "

ตามที่ระบุไว้ก่อนหน้านี้คำแนะนำของฉันคือการโน้มน้าวให้ทำอย่างอื่นหรือทำงาน แต่มันก็เป็นการออกกำลังกายที่สนุกสนานเล็กน้อยในเรื่องไร้สาระ :)


สิ่งนี้น่าสนใจฉันไม่คิดว่าจะใช้ DNS namespaces สองแบบ แต่ฉันเห็นปัญหาต่าง ๆ ได้ที่นี่ ... 1) ไม่มี DC locator records สำหรับ clt.acme.local zone; ดังนั้นลูกค้าจะพบ DC ได้อย่างไร 2) ส่วนต่อท้าย DNS หลักของลูกค้าจะยังคงเป็น acme.local เนื่องจากเป็นสมาชิกโดเมน ดังนั้นฉันเดาว่าพวกเขาจะยังคงค้นหาระเบียน DC locator ในโซนนี้แม้ว่าส่วนต่อท้าย DNS ของ NIC จะแตกต่างกัน 3) อย่างไรก็ตามจะไม่มี DC ที่ลงทะเบียนไว้สำหรับเว็บไซต์ของลูกค้าดังนั้นลูกค้าจะไม่พบสิ่งใดเลย
— Massimo

ผลลัพธ์ที่เป็นไปได้มากที่สุดคือลูกค้าไม่สามารถหา DC ได้เลย (WINS ไม่ได้อยู่ที่นี่และมีการกำหนดเส้นทางเครือข่าย) หรือพวกเขาจะพยายามเชื่อมต่อกับที่อยู่ IP ฝั่งเซิร์ฟเวอร์ของ DC ซึ่งจะไม่ สามารถเข้าถึงได้
— Massimo

@Massimo - ตอบกลับความคิดเห็นในตอนท้ายของโพสต์
— ประกอบ

แต่เมื่อไคลเอนต์ได้รับการบันทึก SRV ว่า "DC ของคุณ it dc1.acme.local" (ไม่ว่าเว็บไซต์จะเป็นอะไร) มันจะไม่พยายามติดต่อกับมันโดยใช้ FQDN หรือไม่ ฉันไม่คิดว่ามันจะสนใจเกี่ยวกับส่วนต่อท้าย DNS ของ NIC เลยฉันไม่คิดว่ามันจะคิดว่า "dc1.acme.local ไม่ตอบลองลอง" dc1.clt.acme.local "มันจะ ลองใช้ dc1.acme.local ซึ่งจับคู่กับที่อยู่ IP ของฝั่งเซิร์ฟเวอร์ของ DC ... และมันจะล้มเหลวหรือฉันจะพลาดบางสิ่งบางอย่างที่นี่
— Massimo

@Massimo - ตอบกลับความคิดเห็นในตอนท้ายของโพสต์
— ประกอบ

3

ในที่สุดฉันก็ไปกับการแก้ปัญหาทั้งสองเว็บไซต์:

  • DC สองตัวสำหรับเครือข่าย "เซิร์ฟเวอร์" สอง DCs สำหรับเครือข่าย "ลูกค้า"
  • สองเว็บไซต์โฆษณาหนึ่งแห่งสำหรับเครือข่าย "เซิร์ฟเวอร์" และอีกแห่งหนึ่งสำหรับ "ลูกค้า"
  • DCs ในเครือข่าย "เซิร์ฟเวอร์" จะมี NIC นั่งอยู่ในนั้น (ลูกค้าจะไม่พูดคุยกับพวกเขาเลย) ดังนั้นนี่จึงเป็นเรื่องง่าย
  • DCs ในโซน "ไคลเอนต์" จะมีสองเครื่อง แต่จะลงทะเบียนใน DNS ที่ไคลเอ็นต์ฝั่งไคลเอ็นต์เท่านั้น
  • เซิร์ฟเวอร์จะพูดคุยกับ DC ของพวกเขาลูกค้าจะพูดคุยกับพวกเขา

แน่นอนนี่หมายถึงการเปิดใช้งานทราฟฟิกการจำลองแบบระหว่างสองเครือข่าย DCs ในเครือข่าย "ลูกค้า" จะยังคงมี NIC อยู่บนเครือข่าย "เซิร์ฟเวอร์" แต่เนื่องจากจะไม่ได้รับการลงทะเบียนใน DNS DCs ในเครือข่ายนั้นจะติดต่อกับพวกเขาโดยใช้ที่อยู่ IP ฝั่งไคลเอ็นต์ ดังนั้นในความเป็นจริง NIC จะไร้ประโยชน์อย่างสมบูรณ์และพอร์ตไฟร์วอลล์บางอันจะต้องเปิดขึ้น ตัวเลือกอื่น ๆ เท่านั้นที่จะจัดการกับhostsไฟล์ของ DC แต่หวังว่าจะสามารถหลีกเลี่ยงได้

ฉันคิดว่านี่เป็นสิ่งที่ดีที่สุดที่สามารถทำได้เพื่อตอบสนองความต้องการ (บ้า) มากที่สุดเท่าที่จะทำได้

ขอบคุณสำหรับคำแนะนำทั้งหมด :-)


2

ก่อนอื่นเมื่อเราให้บริการกับลูกค้าของเราเราควรตั้งคำถามว่าพวกเขาต้องการอะไร การเปิดใช้งานไคลเอนต์ให้เข้าใจว่าระดับความซับซ้อนไม่จำเป็น

  • # ลูกค้าคืออะไร
  • นี่คือการรับส่งข้อมูลภายในทั้งหมดหรือไม่
  • ระดับการทำงานของโดเมนคืออะไร
  • มีการใช้ protcol ของ TLS หรือไม่

ใช้KISS method- จะได้รับการสร้างสอง VLANs "SVR" และ "CLT" การเปิดใช้งาน SSL / TLS และเรียกมันว่าวัน ....

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.