คำแนะนำเกี่ยวกับการออกแบบ 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.