Belajar Active Directory - Read-Only Domain Controllers (RODC)

#Pendahuluan

Di episode 18 kita membangun AD CS dan memahami bagaimana sertifikat memperkuat kepercayaan digital di dalam domain. Di episode 19 ini kita beralih ke persoalan yang sering dihadapi perusahaan dengan banyak kantor: bagaimana melayani autentikasi di kantor cabang yang kecil, terpencil, dan minim staf IT?

Menaruh domain controller (DC) writable di cabang terlihat seperti jawaban yang masuk akal. Tapi kalau cabang itu tidak punya ruang server yang aman, DC-nya bisa dicuri. Kalau cabang itu dipegang staf non-IT, admin lokalnya bisa menyalahgunakan database. Di sinilah Read-Only Domain Controller (RODC) lahir.

#Masalah di Kantor Cabang

Ada tiga tantangan klasik yang membuat kantor cabang tidak ideal untuk DC writable:

• Koneksi WAN yang lambat atau sering putus — tanpa DC lokal, logon ke domain bisa memakan waktu puluhan detik saat link ke pusat bermasalah.
• Keamanan fisik yang rendah — DC berada di lemari kecil atau gudang; siapa pun bisa mencuri hard disk-nya.
• Staf tanpa kompetensi IT — jika orang lokal mendapat akses admin ke DC, mereka bisa memodifikasi direktori atau membocorkan data.

RODC adalah DC yang dirancang untuk tiga skenario ini. Analoginya: RODC seperti salinan dokumen read-only yang disimpan di lokasi terpencil, sedangkan master aslinya tetap di kantor pusat. Di lokasi terpencil, orang bisa membaca dokumen itu untuk bekerja, tapi tidak bisa mengubah isinya.

#Apa Itu RODC

RODC adalah domain controller yang memegang salinan read-only dari database Active Directory. Semua perubahan tetap dilakukan di DC writable, lalu direplikasi ke RODC secara searah (one-way). RODC tidak pernah menjadi sumber perubahan lokal — jika ada pengguna yang harus diganti password-nya, RODC meneruskannya ke DC writable.

Beberapa fakta penting tentang RODC:

• Bisa menjadi Global Catalog dan memegang DNS terintegrasi AD (mode read-only).
• Tidak bisa memegang peran FSMO.
• Replikasi hanya satu arah: dari DC writable menuju RODC.
• Password pengguna hanya disimpan di RODC jika diizinkan oleh Password Replication Policy.

#Fitur Kunci RODC

RODC bukan sekadar "DC yang dibaca saja". Ada empat fitur yang membuatnya aman untuk lokasi terpencil:

• Credential caching — password tidak disimpan sembarangan; hanya akun yang diizinkan yang password-nya di-cache agar bisa logon saat link terputus.
• Administrator role separation — admin lokal RODC hanya mengelola server itu sendiri, tidak punya hak atas DC lain atau domain.
• Filtered attribute set — atribut sensitif (misalnya data tertentu pada akun layanan) bisa di-filter agar tidak pernah direplikasi ke RODC.
• Read-only DNS — zona DNS terintegrasi AD direplikasi satu arah, sehingga zona tidak bisa diubah lewat RODC.

#RODC versus DC Writable

Intinya: kalian mengorbankan kemampuan menulis di lokasi cabang demi keamanan. Trade-off ini sepadan — karena kantor cabang tidak perlu mengubah data, mereka hanya perlu melayani logon.

#Password Replication Policy (PRP)

Password Replication Policy menentukan akun mana yang password-nya boleh disimpan (di-cache) di RODC. Ini fitur pembeda paling penting RODC.

• Denied list — defaultnya berisi akun sensitif seperti Domain Admins, Enterprise Admins, Schema Admins, dan akun krbtgt. Password mereka tidak akan pernah ada di RODC.
• Allowed list — akun biasa (misalnya pengguna cabang dan komputer) yang perlu logon saat link terputus.

Analogi PRP adalah daftar tamu di pos jaga: hanya orang yang namanya tercantum yang boleh menitipkan kartu akses di lokasi. Pencuri yang mencuri RODC hanya mendapat password dari daftar itu — bukan password admin domain.

Mengelola PRP via PowerShell:

Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1" -AllowedList "Domain Users"
Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1" -DeniedList "Domain Admins","Enterprise Admins"
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-Branch1"

#Instalasi RODC (Staged Installation)

Instalasi RODC menggunakan staged installation: akun RODC di-prestage terlebih dahulu di DC writable, lalu server di cabang tinggal dipromosikan. Keuntungannya, perwakilan cabang yang tidak punya hak domain tetap bisa menyelesaikan instalasi tanpa melihat kredensial admin.

Prestage akun RODC di DC pusat:

Add-ADReadOnlyDomainControllerAccount -DomainControllerName "RODC-Branch1" -SiteName "Branch-1" -DomainName "corp.local"
Install-ADDSDomainController -ReadOnlyReplica -DomainName "corp.local" -SiteName "Branch-1" -Credential (Get-Credential)

Setelah dipromosikan, verifikasi bahwa replikasi satu arah berjalan dengan repadmin /replsummary dan cek ketersediaan DC dari klien cabang memakai nltest /dsgetdc:corp.local.

#Mengelola RODC

Setelah berjalan, ada beberapa rutinitas yang perlu diperhatikan:

• Pantau cache credential — gunakan Get-ADDomainControllerPasswordReplicationPolicyUsage untuk melihat akun mana yang password-nya tersimpan di RODC. Semakin sedikit, semakin aman.
• Terapkan GPO khusus RODC — batasi logon lokal, nonaktifkan layanan yang tidak perlu, dan terapkan password policy yang ketat pada akun admin RODC.
• Pisahkan akun admin RODC — jangan pernah memakai akun domain admin untuk login ke RODC; buat akun khusus yang hanya punya hak di server itu.

#Penutup

Di episode ini kalian memahami mengapa RODC adalah pilihan tepat untuk kantor cabang:

• RODC memegang database read-only dengan replikasi satu arah dari DC writable.
• Credential caching dibatasi oleh Password Replication Policy — akun sensitif tidak pernah di-cache.
• Administrator role separation mencegah staf cabang mendapatkan hak domain.
• Staged installation memungkinkan staf non-IT mempromosikan server tanpa kredensial admin.

RODC adalah jembatan antara kebutuhan layanan lokal dan tuntutan keamanan di lokasi yang tidak bisa dijaga penuh. Di episode 20, kita melangkah keluar dari dinding jaringan on-premises: Azure AD Connect dan hybrid identity — menyinkronkan identitas lokal ke Microsoft Entra ID sehingga satu identitas berlaku untuk dunia cloud. Sampai jumpa!