Belajar Active Directory - Active Directory at Scale

#Pendahuluan

Di episode 26 kita memastikan infrastruktur bisa bertahan dari bencana. Sekarang bayangkan skala berbeda: bukan satu kantor dengan 300 karyawan, melainkan 40.000 user tersebar di 60 negara, 8.000 cabang, dan 12 pusat data. Setiap keputusan desain yang tampak sepele di lab — satu DC per situs, satu GC, satu site link — menjadi keputusan mahal yang sulit diubah saat sudah berjalan.

Ini episode tentang desain, bukan sekadar konfigurasi. Di skala besar, kesalahan desain tidak muncul hari ini; ia muncul setahun kemudian sebagai replikasi yang tersendat, logon yang lambat di cabang terpencil, dan biaya operasional yang membengkak. Mari bedah prinsip-prinsip yang membuat AD tetap sehat saat tumbuh menjadi jutaan objek.

#Desain untuk Enterprise: Multi-Domain dan Multi-Forest

Banyak administrator mengira skala berarti banyak domain. Kenyataannya, satu domain modern mampu menampung jutaan objek. Domain baru sebaiknya dibuat karena alasan desain, bukan ketakutan:

• Domain adalah batas administrasi, replikasi, dan kebijakan keamanan. Pecah domain saat kalian butuh isolasi kebijakan yang jelas atau pendelegasian yang tegas.
• Forest adalah batas keamanan dan batas skema. Multi-forest hanya untuk isolasi ekstrem: akuisisi yang belum diintegrasikan, pemisahan kepatuhan, atau persyaratan air-gap.

Pola yang paling umum di enterprise besar: satu forest, beberapa domain, atau bahkan satu forest satu domain dengan OU yang diorganisasi rapi. Setiap domain tambahan berarti replikasi GC, RID pools, dan kompleksitas administrasi yang harus dibayar setiap hari.

#Global Catalog di Skala Besar

Di skala besar, GC bukan lagi "bagus untuk dimiliki" — ia bagian dari jalur logon. Saat user logon, domain controller bertanya ke GC untuk menentukan keanggotaan universal group. Tanpa GC, logon menunggu, menunda, atau gagal.

Prinsip penempatan GC:

• Minimal satu GC per situs, lebih jika beban search lintas-domain tinggi.
• Aplikasi yang mencari lintas-domain (Exchange GAL, tool directory) memakai GC — ukur beban mereka saat merencanakan jumlah GC per hub.
• Untuk situs kecil tanpa GC, aktifkan universal group caching sebagai kompromi: kunci keanggotaan disimpan lokal dan diperbarui berkala, menghemat bandwidth dengan sedikit pengorbanan kekinian.

Di forest multi-domain, setiap GC menyimpan salinan sebagian atribut dari semua domain. Lebih banyak domain berarti lebih banyak data yang direplikasi ke setiap GC — salah satu alasan mengapa "satu forest satu domain" begitu menarik.

#Desain Situs di Skala Besar

Situs adalah peta fisik jaringan AD: subnet dikelompokkan ke situs, lalu dihubungkan oleh site link dengan cost dan jadwal. Di skala besar, kesalahan di sini membebani replikasi selama bertahun-tahun.

• Site link cost menentukan jalur replikasi terbaik antar-situs. Beri cost rendah ke tautan cepat dan mahal, cost tinggi ke tautan lambat dan murah — KCC akan memilih rute paling efisien.
• Jadwal dan frekuensi replikasi mencegah replikasi berebut bandwidth WAN di jam kerja.
• Preferred bridgehead server menunjuk DC tertentu sebagai pintu keluar trafik antar-situs, memudahkan pemantauan dan proteksi.
• Jangan membuat situs untuk setiap gedung atau lantai — situs adalah kumpulan subnet dengan latensi seragam, bukan setiap titik fisik.

Atur site link dengan PowerShell:

Set-ADReplicationSiteLink "DEFAULTIPSITELINK" -Cost 100 -ReplicationFrequencyInMinutes 30

#RODC untuk Cabang

Cabang kecil — toko, gudang, kantor perwakilan — biasanya tidak punya ruang server yang aman. Di sinilah Read-Only Domain Controller (RODC) (episode 19) berperan:

• Database AD read-only; tidak ada tulis langsung, sehingga serangan ke cabang tidak bisa mengubah direktori.
• Password Replication Policy menentukan kredensial siapa yang boleh di-cache di cabang. Akun istimewa secara default masuk daftar denied — pencurian RODC di cabang tidak membocorkan kredensial Domain Admin.
• Admin cabang bisa diberi hak administrasi lokal RODC tanpa mendapat hak domain (administrator role separation).

Aturan praktis: simpan RODC hanya di cabang yang membutuhkan autentikasi lokal yang andal tetapi tidak layak untuk DC writable. Di atas satu RODC per cabang, evaluasi ulang — jangan menumpuk DC di lokasi kecil.

#KCC: Biarkan Ia Bekerja, Tapi Awasi

Knowledge Consistency Checker (KCC) (episode 16) membangun topologi replikasi secara otomatis. Di skala besar, godaan terbesarnya adalah "membantu" KCC dengan membuat connection object manual. Jangan — connection manual bisa membuat topologi menjadi semrawut dan sulit diprediksi.

KCC "di-tune" lewat konfigurasi yang benar, bukan lewat intervensi:

• Setel site link (cost, jadwal) dengan benar — KCC mengikuti petunjuk itu.
• Gunakan site link bridging default; matikan automatic bridging hanya jika topologi sangat kompleks dan kalian paham konsekuensinya.
• Pantau kesehatan topologi secara terjadwal, bukan menunggu keluhan:

repadmin /replsummary /bysrc | Out-File "C:\Data\replsummary.txt"
repadmin /showrepl * /csv | Out-File "C:\Data\repl.csv"

Skrip repadmin /replsummary yang dijalankan oleh scheduled task setiap pagi menjadi alarm dini: error replikasi yang dibiarkan selama seminggu di skala besar bisa berarti puluhan ribu objek tidak sinkron.

#Delegasi dan Otomatisasi di Skala Besar

Administrasi tidak bisa terpusat pada segelintir orang saat skala tumbuh. Gunakan tiga senjata:

1. Delegasi berbasis OU. Helpdesk diberi hak reset password hanya pada OU divisinya masing-masing (episode 7 dan 12). Setiap delegasi harus prinsip least privilege.
2. Pembatasan layanan. Service account di scale dikelola lewat gMSA — password otomatis dirotasi, tanpa admin yang menyimpan rahasia di kepala.
3. Automation. Alur identitas — onboarding saat karyawan masuk, offboarding saat keluar — dijalankan oleh PowerShell dan scheduled task, atau sistem identity lifecycle yang memprovision lewat API.

#Praktik Terbaik Banyak DC

• Jangan menumpuk DC. Dua DC writable per hub site biasanya cukup; tambah hanya karena beban autentikasi atau ketersediaan, bukan karena kebiasaan.
• Patch bertahap. Jangan mem-patch semua DC bersamaan. Satu DC diuji dulu, sisanya menyusul — memastikan AD tetap melayani selama pembaruan.
• Sinkronisasi waktu. PDC Emulator mengambil waktu dari sumber NTP eksternal; semua DC lain ikut dari PDC Emulator. Waktu yang melenceng = kerusakan Kerberos (episode 13).
• Jangan clone DC. Snapshoot atau clone DC virtual membawa risiko USN rollback (episode 26). DC baru harus dipromosi, bukan dikloning.
• Satu DC tambahan bukan jawaban semua masalah. Masalah logon lambat di cabang seringnya DNS dan site design, bukan kurang DC.

#Penutup

Di episode 27 ini kalian memahami AD di skala enterprise: kapan multi-domain dan multi-forest benar-benar dibutuhkan, peran Global Catalog dalam jalur logon dan universal group caching, desain situs lewat site link cost dan bridgehead, RODC sebagai jawaban untuk cabang, prinsip KCC yang di-tune lewat konfigurasi bukan intervensi, delegasi dan otomatisasi sebagai syarat bertahan, serta praktik terbaik banyak DC.

Poin kunci:

• Satu domain modern sanggup menampung jutaan objek; domain baru butuh alasan desain.
• Satu GC per situs adalah standar; universal group caching untuk cabang kecil.
• Jangan melawan KCC — beri dia site link yang benar.
• RODC untuk cabang yang tidak aman, bukan untuk semua lokasi.
• Otomatisasi adalah satu-satunya cara mengelola skala tanpa menambah kesalahan.

Setelah infrastruktur besar, muncul pertanyaan yang tidak bisa dihindari oleh perusahaan besar: bagaimana membuktikan pengendaliannya? Di episode 28 selanjutnya kita bedah Active Directory Compliance & Auditing: regulasi seperti SOX, HIPAA, PCI-DSS, dan GDPR, audit policy, pelaporan akses, hingga change management. Sampai jumpa!