Saran tentang desain Active Directory untuk server multihomed

Saya telah ditugaskan oleh pelanggan untuk membuat desain Active Directory yang berfungsi untuk skenario dengan persyaratan berikut (disederhanakan, sebenarnya jauh lebih buruk):

• Ada subnet untuk sistem klien.
• Ada subnet untuk sistem server.
• Kedua jaringan tidak terhubung.
• Setiap server harus memiliki dua kartu jaringan, satu di jaringan server, yang lain di jaringan klien.
• Lalu lintas antara klien dan server seharusnya hanya mengalir di jaringan klien.
• Lalu lintas antar server hanya boleh mengalir di jaringan server.
• Ini juga berlaku untuk pengontrol domain.

Tidak perlu dikatakan, ini tidak berjalan dengan baik dengan cara Active Directory menggunakan DNS untuk menemukan pengontrol domain; setiap pendekatan yang mungkin akan mengarah pada salah satu skenario berikut:

• DC mendaftarkan alamat IP "sisi klien" mereka di DNS domain; klien akan berbicara dengan mereka menggunakan alamat itu, tetapi begitu juga server, dan lalu lintas replikasi AD.
• DC mendaftarkan alamat IP "sisi server" mereka di DNS domain; server akan berbicara dengan mereka menggunakan alamat itu dan lalu lintas replikasi akan mengalir di jaringan itu, tetapi klien tidak akan dapat menjangkau mereka.
• DC akan mendaftarkan kedua alamat IP dalam DNS domain; siapa pun dapat menebak apa yang akan dilakukan sistem apa pun untuk menjangkau mereka.

Tentu saja, persyaratan ini benar-benar gila dan semuanya tidak dapat dipenuhi secara bersamaan, kecuali menggunakan solusi gila seperti memisahkan layanan DNS pada dua jaringan dan mengisi catatan SRV dengan tangan (argh) atau meminta server mencari DC menggunakan DNS dan klien menemukan DC menggunakan WINS (double-argh).

Solusi yang saya temukan adalah memiliki dua DC pada jaringan "server" dan dua DC pada "klien", mendefinisikan dua situs AD dan melintasi batas antara dua jaringan hanya dengan lalu lintas replikasi DC. Ini masih akan memerlukan beberapa DNS mangling, karena setiap server masih akan memiliki dua kartu jaringan (terlepas dari dua DC sisi-server dan murni back-end server), tetapi setidaknya ada beberapa peluang untuk berfungsi.

Adakah saran, selain melarikan diri secepat mungkin?

Mari saya mulai dengan mengatakan bahwa saya setuju dengan banyak yang lain - baik meyakinkan klien atau menjalankan.

Namun, mengingat persyaratan Anda yang tercantum (ada banyak yang tidak terdaftar), saya dapat memikirkan (dan sebagian diuji) setidaknya dasar untuk membuat ini terjadi.

Ada beberapa aspek khusus yang perlu dipertimbangkan.

1. Replikasi Layanan Domain Direktori Aktif
2. Proses DC Locator dari Klien / Server Anggota
3. Resolusi nama dan lalu lintas untuk layanan non-AD DS

Satu dan dua memiliki banyak kesamaan - secara umum kita berada di kehendak Microsoft yang satu ini dan harus bekerja dalam batas proses AD DS Microsoft.

Nomor tiga, kita punya sedikit ruang untuk bekerja. Kita dapat memilih label yang digunakan untuk mengakses layanan (file, instance database, dll.).

Inilah yang saya usulkan:

Buat Pengontrol Domain Anda (DC)

• Mungkin setidaknya dua.
• Setiap DC akan memiliki dua NIC, satu di setiap jaringan IP / situs AD DS - memanggil mereka clt dan srv untuk saat ini.
• Hanya konfigurasikan satu NIC di setiap DC sekarang di jaringan srv.

Konfigurasikan Situs dan Layanan AD dengan benar

• situs srv dan subnet
• situs clt dan subnet
• hapus centang "Jembatan semua tautan situs" dari Situs -> Pengangkutan Antar Situs -> Klik kanan "IP"
• hapus DEFAULTIPSITELINK jika ada (atau jika Anda menamainya) sehingga tidak ada tautan situs yang dikonfigurasi. Perhatikan bahwa ini adalah yang tidak diketahui untuk saya - KCC kemungkinan akan membuang kesalahan ke log peristiwa Layanan Direktori mengatakan dua situs (srv dan clt) tidak terhubung pada interval yang bervariasi. Namun, replikasi masih akan berlanjut antara dua DC karena mereka dapat saling menghubungi menggunakan IP di situs yang sama.

Konfigurasikan zona tambahan dalam DNS Terintegrasi AD DS

• Jika domain AD DS Anda adalah acme.local , buat Zona Terpadu AD Primer kedua dengan pembaruan dinamis yang diaktifkan yang disebut clt.acme.local .

Konfigurasikan NIC kedua di DC Anda

• NIC ini akan menjadi NIC di jaringan / situs clt.
• Atur IP mereka
• Inilah bagian ajaibnya - Properti Adaptor -> Properti IPv4 -> Lanjutan -> Tab DNS -> Atur akhiran DNS untuk koneksi ini ke clt.acme.local -> centang Daftarkan koneksi ini ... -> Periksa Gunakan koneksi ini Akhiran DNS ... -> OK sepanjang jalan.
• ipconfig / registerdns
• Ini akan mendaftarkan IP NIC clt di zona clt.acme.local - menyediakan metode bagi kami untuk mengontrol IP / jaringan mana yang digunakan nanti.

Konfigurasikan server anggota NIC

• Server anggota NIC di situs clt harus memiliki akhiran DNS dan kotak centang yang ditetapkan juga seperti di atas.
• Pengaturan ini dapat digunakan dengan statis dan DHCP, tidak masalah.

Konfigurasikan perilaku penyelesaian DNS [stub] di situs

• DC -> Konfigurasikan DC srv NIC untuk menggunakan dirinya sendiri dan IP DC srv NIC lainnya. Biarkan DC clt NIC DNS kosong (IP statis diperlukan meskipun). (DC DNS server akan tetap mendengarkan semua IP secara default).
• Server anggota -> Konfigurasikan server anggota srv NIC untuk menggunakan IP situs DC srv. Biarkan server anggota clt NIC DNS kosong (IP statis dapat digunakan).
• Klien / Workstation -> Mengkonfigurasi DNS (baik melalui DHCP atau statis) untuk menggunakan IP NIC IP clt DC.

Konfigurasikan pemetaan / sumber daya dengan tepat

• Ketika server berbicara satu sama lain, pastikan untuk menggunakan .acme.local -> akan memutuskan untuk IP jaringan srv.
• Ketika klien berbicara dengan server, pastikan untuk menggunakan .clt.acme.local -> akan memutuskan untuk menggunakan IP jaringan.

Apa yang saya bicarakan?

• Replikasi AD DS akan tetap terjadi karena DC dapat saling menyelesaikan, dan terhubung satu sama lain. Zona acme.local dan _msdcs.acme.local hanya akan berisi replikasi AD DS IP NIC IP srv DC hanya akan terjadi pada jaringan srv.
• Proses locator DC untuk server anggota dan workstation akan berfungsi - walaupun ada kemungkinan penundaan di berbagai bagian dari berbagai proses AD DS ketika situs tidak diketahui, jika beberapa DC IP dikembalikan - mereka akan dicoba, gagal, dan dilanjutkan sampai seseorang bekerja. Efek pada DFS-N belum sepenuhnya dievaluasi - tetapi masih akan berfungsi.
• Layanan Non AD DS akan berfungsi dengan baik jika Anda menggunakan label .acme.local dan .clt.acme.local tersebut seperti yang dijelaskan.

Saya belum sepenuhnya menguji ini karena agak menggelikan. Namun, inti dari jawaban (wow, panjang) ini adalah untuk mulai mengevaluasi apakah itu mungkin atau tidak - bukan apakah itu harus dilakukan.

@ Komentar

@ Massimo 1/2 Jangan membingungkan banyak situs DS AD di zona acme.local, dan dengan demikian catatan SRV yang dihuni oleh DC di situs-situs di zona acme.local dengan membutuhkan catatan SRV di zona clt.acme.local. Sufiks DNS primer klien (dan domain Windows tempat mereka bergabung) masih akan menjadi acme.local. Klien / workstation hanya memiliki NIC tunggal, dengan akhiran DNS primer kemungkinan berasal dari DHCP, diatur ke acme.local.

Zona clt.acme.local tidak perlu catatan SRV karena tidak akan digunakan dalam proses locator DC. Ini hanya digunakan oleh klien / workstation untuk terhubung ke layanan non-AD DS server anggota menggunakan IP server anggota di jaringan clt. Proses terkait AD DS (DC locator) tidak akan menggunakan zona clt.acme.local, tetapi situs AD DS (dan subnet) di zona acme.local.

@ Massimo 3

Akan ada catatan SRV untuk situs AD DS clt dan srv - hanya saja mereka akan ada di zona acme.local - lihat catatan di atas. Zona clt.acme.local tidak perlu catatan SRV terkait DC.

Klien akan dapat menemukan denda DC. Server DNS klien menunjuk ke IP clt dari DC.

Ketika proses locator DC pada klien dimulai

• Jika klien mengetahui situsnya, pertanyaan DNSnya adalah _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Ini akan mengembalikan DC situs spesifik yang memiliki catatan SRV terdaftar.
• Jika klien tidak tahu situsnya, pertanyaan DNSnya adalah _ldap._tcp.dc._msdcs.acme.local SRV. Ini akan mengembalikan semua DC. Klien akan berusaha untuk mengikat LDAP DC hingga menemukan yang merespons. Ketika klien menemukan satu, itu melakukan pencarian situs untuk menentukan situs klien, dan cache situs di registri sehingga contoh DC locator masa depan terjadi lebih cepat.

@ Massimo 4

Ugh, tangkapan yang bagus. Cara saya melihatnya ada dua cara untuk mengatasi masalah ini.

1. Dampak yang lebih kecil (dibandingkan dengan 2 di bawah) adalah untuk membuat entri di file host pada klien / workstation untuk dc1.acme.local dan dc2.acme.local menunjuk ke clt NIC IP dari DC.

atau

2. Secara manual membuat catatan SRV yang diperlukan dalam file netlogon.dns pada masing-masing DC. Ini kemungkinan akan memiliki beberapa konsekuensi pada jaringan server. Server anggota kadang-kadang dapat berkomunikasi dengan DC di jaringan clt jika ini dikonfigurasi.

Semua dalam semua tidak ada yang cantik, tapi itu belum tentu tujuan akhir. Mungkin klien hanya menguji daging teknologi Anda. Taruh di meja konferensi mereka dan beri tahu mereka "Ini, ini akan berhasil, tapi saya menagih Anda 4x tingkat normal saya untuk mengonfigurasi dan mendukungnya. Anda dapat menguranginya menjadi 1,5x tingkat normal saya - .5x biaya PITA, dengan melakukan [solusi yang benar]. "

Seperti disebutkan sebelumnya, rekomendasi saya adalah meyakinkan sebaliknya atau menjalankan. Tapi itu sedikit latihan yang menyenangkan dan konyol. :)

Pada akhirnya saya pergi dengan solusi dua situs:

• Dua DC untuk jaringan "server", dua DC untuk jaringan "klien".
• Dua situs AD, satu untuk jaringan "server" dan satu untuk "klien".
• DC di jaringan "server" hanya akan memiliki NIC yang duduk di situ (klien tidak akan berbicara sama sekali dengan mereka), jadi ini mudah.
• DC di zona "klien" akan memiliki dua, tetapi hanya akan mendaftar di DNS yang berada di sisi klien mereka.
• Server akan berbicara dengan DC mereka, klien akan berbicara dengan mereka.

Tentu saja, ini berarti memungkinkan lalu lintas replikasi antara dua jaringan; DC di jaringan "klien" masih akan memiliki NIC yang berada di jaringan "server", tetapi karena tidak akan terdaftar di DNS, DC di jaringan itu akan menghubungi mereka menggunakan alamat IP sisi klien mereka; sehingga NIC sebenarnya akan sama sekali tidak berguna, dan beberapa port firewall perlu dibuka. Satu-satunya pilihan lain adalah mengatur hostsfile - file DC , tetapi mari kita berharap hal itu dapat dihindari.

Yah, saya pikir ini adalah yang terbaik yang bisa dilakukan untuk memenuhi sebanyak mungkin persyaratan (gila).

Terima kasih atas semua saran :-)

Pertama-tama, ketika kami memberikan layanan kepada pelanggan kami, kami harus mempertanyakan apa persyaratan mereka. Memungkinkan klien untuk memahami bahwa tingkat kerumitannya tidak perlu.

• Apa yang # klien?
• Ini semua lalu lintas internal?
• Apa tingkat fungsional domain?
• Apakah protol TLS digunakan?

Menggunakan metode KISS - Akan membuat dua VLAN "SVR" dan "CLT" memungkinkan SSL / TLS dan menyebutnya Hari ....