Belajar Active Directory - Active Directory Replication

#Pendahuluan

Pada episode 15 kita mengatur siapa yang boleh melakukan apa — di file, di folder, dan di objek AD. Sekarang pertanyaan yang lebih dalam: dengan banyaknya Domain Controller di sebuah domain, bagaimana bisa setiap DC menyimpan informasi yang sama? Bagaimana perubahan yang kalian buat di DC Jakarta bisa sampai ke DC Surabaya dan DC Makassar? Jawabannya adalah replikasi.

Dari episode 6 kalian tahu bahwa AD menganjurkan lebih dari satu DC untuk fault tolerance. Tapi janji itu hanya bermakna jika semua DC benar-benar memiliki data yang sama. Bayangkan sebuah kantor dengan banyak resepsionis yang masing-masing memegang buku catatan daftar karyawan. Jika ada yang mencatat karyawan baru tapi tidak menyinkronkan bukunya dengan yang lain, kekacauan terjadi: di meja A orang itu "sudah diterima", di meja B dia "tidak dikenal". Replikasi adalah mekanisme yang memastikan semua buku catatan itu sama — otomatis, terus-menerus, dan tahan terhadap kegagalan.

#Multi-Master Replication: Tidak Ada Raja Tunggal

Model replikasi AD disebut multi-master: setiap writable DC bisa menerima perubahan apa pun dan "menyiarkan" perubahan itu ke DC lain. Tidak ada satu DC yang menjadi sumber kebenaran tunggal — tidak seperti model master-slave di sistem lain.

Keuntungannya jelas: tidak ada single point of failure. DC mana pun bisa offline, dan yang lain tetap melayani autentikasi serta perubahan. Tetapi model ini membawa tantangan tersendiri: bagaimana memastikan perubahan yang dilakukan bersamaan di dua DC tidak saling menimpa? Jawabannya adalah USN.

#USN: Nomor Urut Setiap Perubahan

USN (Update Sequence Number) adalah nomor yang terus naik dan dimiliki setiap DC. Setiap kali sebuah atribut objek diubah, DC memberikan nomor USN baru yang lebih besar dari sebelumnya. Dengan USN ini, replikasi menjadi proses yang rapi:

1. Setiap DC mencatat "USN tertinggi yang sudah saya terima dari DC lain" (disebut high watermark).
2. Saat mereplikasi, DC meminta "perubahan dengan USN lebih besar dari angka yang sudah saya punya".
3. DC pengirim memberikan semua perubahan itu, dan penerima memperbarui watermark-nya.

Analoginya seperti buku log dengan nomor halaman: "semua yang saya catat setelah halaman 42, kirimkan ke saya." Inilah yang membuat replikasi incremental — hanya perubahan yang dikirim, bukan seluruh database.

Replikasi AD juga bekerja per-atribut, bukan per-objek penuh. Jika satu user hanya mengganti nomor telepon, DC lain hanya menerima perubahan atribut itu — hemat bandwidth dan cepat.

repadmin /showobjmeta DC02 "cn=Joko Santoso,ou=Karyawan,dc=corp,dc=local"

#Replikasi Intra-Site vs Inter-Site

AD membedakan dua jenis replikasi berdasarkan jarak fisik jaringan:

#Intra-Site

Di dalam satu site, DC saling berhubungan dalam pola ring yang dihasilkan otomatis oleh KCC (Knowledge Consistency Checker) — "arsitek topologi" AD. Ketika sebuah DC membuat perubahan, ia mengirim notifikasi ke DC berikutnya dalam ring, dan perubahan mengalir dengan cepat. Replikasi di sini mengejar kecepatan, bukan hemat bandwidth.

#Inter-Site

Antar site, AD memakai site links yang kalian definisikan di Active Directory Sites and Services — lengkap dengan cost, schedule, dan interval replikasi. Site link berbiaya rendah berarti preferensi jalur; schedule menentukan kapan replikasi boleh berjalan (misalnya hanya malam hari untuk link 2 Mbps). Alih-alih semua DC saling bicara, bridgehead server di setiap site bertindak sebagai perwakilan — satu DC yang bertukar data dengan site lain.

Inilah alasan konfigurasi sites sangat penting: jika kalian tidak mendefinisikan subnet dan site dengan benar, klien di kantor cabang bisa "memilih" DC yang jauh karena dianggap site yang sama — lambat dan boros link.

#Urgent Replication

Tidak semua perubahan menunggu jadwal. Dua jenis perubahan dianggap urgent dan langsung direplikasi melintasi site link:

• Perubahan password — untuk mencegah user memakai password lama di DC yang belum menerima update.
• Akun terkunci (account lockout) — agar kebijakan lockout konsisten di seluruh DC.

Ini penting untuk dipahami karena berpengaruh pada pengalaman user: reset password yang "belum nyampe" sering membuat user gagal login — gejalanya familiar bagi admin helpdesk.

#KCC: Arsitek yang Menjaga Jalan Terhubung

KCC adalah mesin yang memastikan setiap DC selalu punya jalur replikasi ke DC lain. Ia mengevaluasi topologi secara berkala, membuat connection objects yang dibutuhkan, dan memperbaiki sendiri jika ada DC yang mati atau site link yang berubah. Ketika sebuah DC di-promote, KCC otomatis membangun koneksinya. Ketika DC lain mati, KCC menyusun ulang ring agar replikasi tetap mengalir.

Peran KCC inilah yang membuat AD "menyembuhkan dirinya sendiri" untuk masalah konektivitas — selama DNS dan jaringan sehat.

#RID Pool dan Tombstone

Dua konsep yang sering muncul bersamaan dengan replikasi:

• RID Pool. Setiap kali DC membuat objek keamanan (user, group), ia memakai RID (Relative Identifier) untuk membentuk SID unik. RID diambil dari pool yang dialokasikan RID Master (salah satu FSMO role, dari episode 3). Jika pool sebuah DC habis — misalnya setelah membuat jutaan objek — DC itu tidak bisa membuat objek baru sampai RID Master mengalokasikan pool berikutnya. Memantau sisa pool mencegah "kehabisan bahan baku" yang diam-diam memblokir pembuatan user.
• Tombstone. Objek yang dihapus di AD tidak langsung lenyap — ia diubah menjadi tombstone (penanda kematian) yang hidup selama tombstone lifetime (default 180 hari di AD modern). Tujuannya: replikasi bisa menyebarkan penghapusan ke seluruh DC, dan DC yang lama offline bisa "belajar" bahwa objek itu sudah mati. Ini jembatan menuju topik backup dan recovery di episode 17.

#Memantau Replikasi dengan repadmin

Alat utama admin replikasi adalah repadmin — misalnya repadmin /replsum untuk ringkasan kesehatan. Tiga perintah yang wajib kalian kuasai:

repadmin /replsum

repadmin /replsum memberi ringkasan satu layar: per DC, berapa banyak kegagalan, berapa banyak sukses, dan berapa persen yang terlambat. Ini adalah "dashboard pertama" sebelum menyelam lebih dalam.

repadmin /showrepl

repadmin /showrepl menampilkan detail per destination dan source: koneksi mana yang sehat, mana yang gagal terakhir kali, dan kapan. Untuk per-DC:

repadmin /showrepl DC02 -verbose

Untuk memaksa semua DC menyinkronkan dengan semua rekannya (berguna setelah perbaikan):

repadmin /syncall -A

#Troubleshooting Replikasi

Ketika replikasi gagal, gejalanya khas: password "lama" terus tertolak di satu DC, user yang diubah tidak muncul di DC lain, atau GPO tidak konsisten. Beberapa error yang paling sering:

• Error 1722 (RPC server unavailable) — DC tidak bisa dihubungi: firewall memblokir port RPC (135, 49152-65535), atau service tidak berjalan. Periksa konektivitas dan service Kerberos/RPC.
• Error 8524 (DSA operational failure) — kegagalan umum pada replikasi outgoing, sering karena masalah keamanan atau kredensial antar DC, kadang USN rollback atau masalah DNS.
• Error 1256 — source dan destination bukan rekan replikasi langsung, atau topologi sedang diperbaiki KCC.

Urutan diagnosis yang disarankan:

1. Cek DNS dulu. Replikasi bergantung pada resolusi nama DC lain. Jika nslookup gagal, perbaiki ini sebelum menyalahkan replikasi.
2. Cek konektivitas. Pastikan port RPC terbuka antar DC dan jam tersinkron.
3. Baca event log. Log Directory Service (event 1311, 1925, 2042) menunjuk langsung ke masalahnya.
4. Cek dengan repadmin. repadmin /replsum lalu repadmin /showrepl mempersempit lokasi kegagalan.
5. Perbaiki dan verifikasi. Setelah sumber masalah diperbaiki, paksa replikasi dengan repadmin /syncall -A dan pastikan counter gagal turun.

Dua kondisi serius yang harus kalian waspadai: USN rollback (DC yang dipulihkan dari backup lama "memundurkan" USN-nya, memicu event 2042 dan bisa merusak konsistensi data) dan lingering objects (objek yang sudah dihapus di DC lain tapi masih hidup di satu DC — residu yang sulit dihapus). Keduanya butuh intervensi hati-hati, dan sering kali jalur terbaik adalah demote, bersihkan, lalu promote kembali.

#Penutup

Pada episode ini kita telah membedah replikasi Active Directory: model multi-master yang membuat setiap DC writable, mekanisme USN sebagai nomor urut perubahan dan high watermark untuk sinkronisasi incremental, perbedaan intra-site yang cepat dan inter-site yang hemat bandwidth, peran KCC dan bridgehead servers, RID pool sebagai bahan baku SID, tombstone sebagai penanda penghapusan, serta pemantauan dan troubleshooting lewat repadmin dengan error 1722, 8524, dan 1256.

Inti dari episode ini: replikasi adalah sistem yang dirancang untuk menyembuhkan diri sendiri — selama fondasinya (DNS, jaringan, waktu) sehat. Pemantauan rutinlah yang membuat DC berjumlah banyak terasa seperti satu direktori, bukan sekumpulan buku catatan yang tidak sinkron.

Di episode 17 selanjutnya, kita mempersiapkan diri menghadapi yang terburuk: Active Directory Backup & Recovery — dari system state backup dan ntdsutil, restorasi authoritative dan non-authoritative, Active Directory Recycle Bin, hingga prosedur forest recovery. Pastikan tetap semangat!