Memulihkan dan memperbaiki pengontrol domain lokal yang rusak.

Ketika pengendali domain mengalami kerusakan atau pemulihan yang salah, dampaknya sangat besar: login gagal, GPO berhenti diterapkan, dan replikasi terhenti tanpa peringatan yang memadai . Kabar baiknya adalah terdapat prosedur yang jelas untuk memulihkan pengendali domain fisik atau virtual, asalkan metode pencadangan dan pemulihan yang didukung diikuti.

Dalam lingkungan Windows Server modern, memulihkan pengendali domain memerlukan pemahaman yang mendalam tentang konsep-konsep seperti status sistem, pemulihan otoritatif/non-otoritatif, SYSVOL, DFSR/FRS, dan pengembalian USN . Jika masalah-masalah ini ditangani secara tergesa-gesa atau dengan alat pencitraan yang tidak didukung, hasilnya dapat berupa serangkaian inkonsistensi tersembunyi yang sangat sulit didiagnosis.

Mengapa sangat penting untuk melindungi dan memulihkan pengendali domain dengan benar

Active Directory adalah inti dari otentikasi dan otorisasi dalam domain Windows : ia menyimpan pengguna, komputer, grup, hubungan kepercayaan, kebijakan grup, sertifikat, dan elemen penting lainnya. Informasi ini terutama berada di basis data Ntds.dit , file log terkait, dan folder SYSVOL , di antara komponen lain yang membentuk apa yang disebut "status sistem".

Status sistem mencakup, antara lain, file log dan data Active Directory, Registri Windows, volume sistem, SYSVOL, basis data sertifikat (jika ada CA), metabase IIS, file boot, dan komponen sistem operasi yang dilindungi . Oleh karena itu, strategi kelangsungan bisnis yang serius harus mencakup pencadangan rutin status sistem dari setiap pengendali domain.

Ketika terjadi kerusakan basis data Active Directory yang sebenarnya, kegagalan replikasi yang serius, atau masalah izin SYSVOL , pengendali domain dapat berhenti memproses kueri, gagal memulai layanan Active Directory, atau memicu kesalahan berantai di seluruh forest. Dalam kasus ini, pemulihan yang cepat dan berhasil membuat perbedaan antara insiden serius dan bencana yang berkepanjangan.

Sebelum mencoba melakukan pemulihan, sangat penting untuk membedakan antara masalah basis data yang sebenarnya dan masalah yang lebih umum. Seringkali, penyebabnya terletak pada DNS, perubahan jaringan, firewall, atau jalur yang dimodifikasi dengan alat seperti perintah netsh , jadi disarankan untuk mengesampingkan faktor-faktor ini terlebih dahulu sebelum menyentuh basis data Active Directory.

Alat diagnostik dan kontrol replikasi dasar

Jika Anda menemukan gejala korupsi atau kegagalan replikasi, langkah pertama yang masuk akal adalah memeriksa status lingkungan menggunakan alat bawaan. DCDiag, Repadmin, ReplMon (pada versi lama), dan Event Viewer adalah sekutu terbaik Anda sebelum mempertimbangkan pemulihan yang agresif.

DCDiag melakukan pemeriksaan umum pada semua pengendali domain, mengidentifikasi masalah dengan replikasi, DNS, layanan AD DS, dan banyak lagi. Repadmin memungkinkan Anda untuk melihat status replikasi, mitra replikasi, tanda air USN, dan mendeteksi objek persisten. Pada versi Windows yang lebih lama, ReplMon menawarkan tampilan grafis kesalahan replikasi di dalam domain.

Selain alat-alat tersebut, penting untuk meninjau Event Viewer untuk "Directory Services" dan "DFS Replication". Kejadian seperti 467 dan 1018 menunjukkan kerusakan basis data yang sebenarnya , sedangkan kejadian 1113, 1115, 1114, dan 1116 berkaitan dengan mengaktifkan atau menonaktifkan replikasi masuk/keluar.

Jika DC yang dicurigai perlu diisolasi sementara untuk mencegah penyebaran korupsi, kita dapat menonaktifkan replikasi masuk dan keluar dengan Repadmin :

repadmin /options DCNAME +DISABLE_INBOUND_REPL
repadmin /options DCNAME +DISABLE_OUTBOUND_REPL

Dan untuk mengembalikan replikasi ke kondisi normal, cukup hapus opsi-opsi tersebut:

repadmin /options DCNAME -DISABLE_INBOUND_REPL
repadmin /options DCNAME -DISABLE_OUTBOUND_REPL

Mendukung pencadangan status sistem pada pengendali domain.

Untuk memulihkan pengendali domain secara andal, sangat penting untuk membuat cadangan status sistem menggunakan alat yang kompatibel dengan Active Directory . Alat-alat ini memanfaatkan API pencadangan dan pemulihan Microsoft serta Layanan Salinan Bayangan Volume (VSS) dengan cara yang didukung.

Beberapa solusi yang paling umum digunakan antara lain Windows Server Backup, solusi pihak ketiga yang terintegrasi dengan VSS (seperti NAKIVO, Backup Exec, dan lainnya) , atau utilitas lama seperti Ntbackup di Windows 2000/2003. Dalam semua kasus, solusi tersebut harus mematuhi API Active Directory (AD) untuk memastikan konsistensi basis data dan replikanya setelah pemulihan.

Windows Server 2012 dan versi yang lebih baru memperkenalkan fitur baru yang penting: Hyper-V Generation ID (GenID) . Pengidentifikasi ini memungkinkan pengendali domain virtual untuk mendeteksi kapan disk-nya telah dikembalikan ke titik waktu sebelumnya. Ketika ini terjadi, Active Directory Domain Services (AD DS) menghasilkan Invocation ID baru dan memperlakukan situasi tersebut seolah-olah telah dipulihkan dari cadangan yang berhasil , memberi tahu mitra replikasinya dan memungkinkan penulisan ulang yang aman tanpa memicu pengembalian USN.

Sangat penting untuk menghormati masa berlaku tombstone , yang menentukan berapa lama cadangan status sistem dapat digunakan tanpa risiko munculnya kembali objek yang telah dihapus sejak lama. Biasanya, masa berlakunya adalah 180 hari pada versi modern, dan disarankan untuk melakukan pencadangan setidaknya setiap 90 hari untuk menjaga margin keamanan yang memadai.

Metode tidak sah yang menyebabkan pembalikan USN.

Salah satu penyebab paling berbahaya dari inkonsistensi diam-diam di Active Directory adalah rollback USN . Hal ini terjadi ketika isi basis data AD di-rollback menggunakan teknik yang tidak didukung, tanpa mengatur ulang InvocationID atau memberi tahu mitra replikasi.

Skenario tipikal melibatkan booting pengendali domain dari citra disk atau snapshot mesin virtual yang diambil di masa lalu , tanpa menggunakan pemulihan sistem yang kompatibel. Opsi lain termasuk menyalin file Ntds.dit secara langsung, menggunakan perangkat lunak pencitraan seperti Ghost, melakukan booting dari mirror disk yang rusak, atau menerapkan kembali snapshot penyimpanan pada tingkat array.

Dalam kasus ini, pengendali domain terus menggunakan InvocationID yang sama seperti sebelumnya, tetapi penghitung USN lokalnya kembali ke versi sebelumnya . Pengendali domain lainnya mengingat telah menerima perubahan hingga jumlah USN yang tinggi, sehingga ketika pengendali domain yang dikembalikan ke versi sebelumnya mencoba mengirimkan USN yang dikenali lagi, mitranya percaya bahwa mereka sudah mutakhir dan berhenti menerima perubahan tertentu.

Akibatnya, modifikasi tertentu (misalnya, pembuatan pengguna, perubahan kata sandi, penambahan perangkat, perubahan keanggotaan grup, catatan DNS baru ) tidak pernah direplikasi dari pengendali domain yang dipulihkan ke seluruh jaringan, tetapi alat pemantauan mungkin tidak menunjukkan kesalahan yang jelas. Ini adalah kerentanan tersembunyi yang sangat berbahaya.

Untuk mendeteksi situasi ini, driver Windows Server 2003 SP1 dan yang lebih baru mencatat peristiwa Layanan Direktori 2095 ketika pengendali domain (DC) jarak jauh terdeteksi mengirimkan USN yang sebelumnya telah dikonfirmasi tanpa InvocationID yang berubah. Ketika ini terjadi, sistem mengkarantina DC yang terpengaruh, menghentikan sementara Netlogon, dan mencegah perubahan lebih lanjut yang tidak dapat direplikasi dengan sukses.

Sebagai bukti forensik lebih lanjut, Anda dapat memeriksa kunci Registry HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters dan nilai Dsa Not Writable . Jika nilai ini diatur (misalnya, 0x4), ini menunjukkan bahwa DC telah ditempatkan dalam keadaan bebas tulis dengan mendeteksi rollback USN. Memodifikasi nilai ini secara manual untuk "memperbaikinya" sama sekali tidak didukung dan membuat basis data berada dalam keadaan tidak konsisten secara permanen.

Strategi umum jika terjadi kerusakan atau pengembalian kendali domain.

Cara menangani DC yang rusak atau dipulihkan secara tidak benar bergantung pada beberapa faktor: jumlah pengendali domain dalam domain/forest, ketersediaan salinan status sistem yang valid, keberadaan peran lain (FSMO, CA, katalog global) dan cakupan waktu masalah.

Jika terdapat pengendali domain lain yang sehat di domain tersebut dan tidak ada data penting unik yang berada di pengendali domain yang gagal , opsi tercepat dan terbersih biasanya adalah menghapus dan membangun kembali pengendali domain tersebut. Namun, jika itu adalah satu-satunya pengendali domain, atau jika pengendali domain tersebut menyimpan peran dan data sensitif, pemulihan yang lebih hati-hati (otoritatif atau non-otoritatif) akan diperlukan.

Secara umum, pilihannya adalah:

• Turunkan pangkat DC yang korup secara paksa dan hapus dari domain., diikuti dengan pembersihan metadata dan, jika berlaku, promosi baru.
• Pulihkan dari cadangan status sistem yang valid., baik dalam mode otoritatif maupun non-otoritatif.
• Bangun ulang DC dari DC lain menggunakan IFM (Install From Media)., ketika tidak ada salinan terbaru tetapi ada DC lain yang benar.
• Menggunakan snapshot VHD dari DC virtual., menerapkan langkah-langkah tambahan untuk menandai basis data sebagai telah dipulihkan dari cadangan (Basis data dipulihkan dari cadangan = 1) dan memastikan bahwa InvocationID baru dihasilkan.

Jika rollback USN jelas dicurigai (misalnya, setelah memulihkan VM dari snapshot tanpa mengikuti praktik terbaik) dan event 2095 muncul, hal yang paling masuk akal untuk dilakukan biasanya adalah menghapus DC tersebut dari layanan dan tidak mencoba untuk "memperbaikinya" di tempat , kecuali Anda dapat kembali ke cadangan status sistem yang didukung yang diambil sebelum rollback.

Penurunan pangkat paksa dan pembersihan metadata

Ketika pengendali domain mengalami kerusakan sedemikian rupa sehingga tidak dapat diturunkan secara normal, atau telah dipulihkan secara tidak benar dan Anda ingin mencegahnya menyebarkan masalah, Anda dapat menggunakan metode penurunan paksa (forced demo).

Pada versi lama, operasi ini dilakukan dengan `dcpromo /forceremoval` , yang menghapus peran AD DS tanpa mencoba mereplikasi perubahan ke seluruh forest . Di lingkungan modern, wizard telah berubah, tetapi konsepnya tetap sama: untuk menghapus DC yang bermasalah dari topologi AD tanpa membuatnya berpartisipasi dalam replikasi lebih lanjut.

Setelah penurunan pangkat paksa, wajib dilakukan pembersihan metadata dari pengendali domain yang sehat menggunakan alat Ntdsutil . Proses ini menghapus semua referensi ke pengendali domain yang dihapus dari basis data Active Directory (objek Pengaturan NTDS, referensi DNS, dll.), memastikan bahwa tidak ada sisa "hantu" yang tersisa untuk mengganggu replikasi.

Jika pengendali domain yang diturunkan jabatannya memegang peran FSMO (PDC Emulator, RID Master, Schema Master, dll.), peran-peran ini harus dipindahkan atau diambil alih ke pengendali domain lain sebelum atau setelah penurunan jabatan, tergantung pada situasinya. Setelah itu, sistem operasi dapat diinstal ulang pada server tersebut, dan server tersebut dapat dipromosikan kembali menjadi pengendali domain yang bersih.

Pemulihan non-otoritatif vs. otoritatif di Active Directory

Ketika salinan status sistem yang valid tersedia, pemulihan Active Directory dapat dilakukan dengan dua cara: non-otoritatif dan otoritatif . Memahami perbedaannya sangat penting untuk menghindari hilangnya perubahan terbaru atau replikasi data yang sudah usang.

Dalam pemulihan non-otoritatif , pengendali domain dikembalikan ke keadaan sebelumnya, tetapi setelah booting, pengendali domain lain dianggap sebagai referensi . Artinya, setelah booting, pengendali domain yang dipulihkan meminta replikasi masuk dan memperbarui basis datanya dengan perubahan yang hilang dari pengendali domain lain. Opsi ini ideal ketika ada pengendali domain lain yang sehat dan kita ingin pengendali domain yang dipulihkan untuk mengejar ketertinggalan dengan mereka.

Sebaliknya, dalam pemulihan otoritatif , secara eksplisit dinyatakan bahwa data yang dipulihkan harus didahulukan daripada data yang dimiliki oleh pengendali domain (DC) lainnya. Ini berarti bahwa, setelah pemulihan, objek yang dipulihkan akan memiliki nomor versi yang lebih tinggi untuk memaksa replikasi dari DC tersebut ke seluruh domain. Ini adalah pilihan yang tepat ketika kita secara tidak sengaja menghapus objek atau unit organisasi (OU), atau ketika kita ingin mengembalikan isi SYSVOL dan GPO ke keadaan sebelumnya dan mereplikasikannya.

Detail pentingnya adalah bahwa pemulihan otoritatif tidak harus untuk seluruh basis data. Utilitas Ntdsutil memungkinkan Anda untuk menandai objek individual, subpohon (misalnya, OU), atau seluruh domain sebagai otoritatif. Ini menawarkan fleksibilitas yang cukup besar, memungkinkan Anda untuk, misalnya, memulihkan hanya pengguna, grup, OU, atau subpohon dc=mycompany,dc=local.

Prosedur umum untuk memulihkan status sistem di DC.

Skema dasar untuk memulihkan status sistem DC (baik fisik maupun virtual) dengan alat yang kompatibel selalu serupa: boot ke Directory Services Restore Mode (DSRM), pulihkan dengan alat pencadangan, dan mulai ulang.

Singkatnya, langkah-langkah umum untuk pengendali domain virtual adalah:

1. Mulai mesin virtual di Windows Boot Manager. (biasanya dengan menekan F5/F8 selama proses startup). Jika VM dikelola oleh hypervisor, mungkin perlu untuk menghentikan sementara mesin agar dapat merekam penekanan tombol.
2. Di opsi boot lanjutan, pilih Mode pemulihan layanan direktori (Mode Pemulihan Layanan Direktori). Mode ini memulai server tanpa memasang basis data Active Directory secara fungsional.
3. Masuk menggunakan akun administrator DSRM ditentukan selama promosi awal DC (bukan dengan akun administrator domain standar).
4. Jalankan alat pencadangan Gunakan (Windows Server Backup, NAKIVO, atau yang kompatibel lainnya) dan pilih untuk memulihkan status sistem ke titik pencadangan yang diinginkan.
5. Selesaikan panduan pemulihan dan Mulai ulang DC dalam mode normal.Dalam pemulihan non-otoritatif, server akan memulai replikasi untuk mengejar ketertinggalan dengan DC lainnya.

Ketika kita berbicara tentang produk pencadangan pihak ketiga, seperti NAKIVO Backup & Replication , mode "app-aware" mereka dapat mengenali bahwa mesin yang sedang dipulihkan adalah pengendali domain dan secara otomatis menyesuaikan proses untuk menjaga konsistensi Active Directory . Dalam sebagian besar skenario dengan beberapa pengendali, pemulihan penuh dalam mode non-otoritatif sudah cukup.

Restorasi resmi dengan Ntdsutil

Jika Anda ingin perubahan pada pengendali domain yang dipulihkan diutamakan daripada yang lain, Anda perlu menambahkan langkah tambahan setelah pemulihan non-otoritatif: gunakan Ntdsutil untuk menandai objek sebagai otoritatif.

Alur yang disederhanakan adalah:

1. Pulihkan status sistem dengan cara standar dan biarkan server tetap dalam keadaan tersebut. Mode DSRM (Jangan memulai ulang dalam mode normal dulu).
2. Buka prompt perintah dengan hak akses administrator dan lari ntdsutil.
3. Aktifkan instance AD ​​dengan aktifkan instance ntds.
4. Memasuki konteks restorasi otoritatif dengan pemulihan yang berwibawa.
5. Gunakan perintah seperti restore object <DN_objeto> o restore subtree <DN_subarbol>, di mana DN adalah nama pembeda dari objek atau subpohon yang akan dipulihkan secara otoritatif.
6. Konfirmasikan transaksi dan, setelah selesai, Mulai ulang DC dalam mode normal. sehingga objek yang ditandai direplikasi dengan prioritas lebih tinggi daripada objek lain dalam domain tersebut.

Jenis pemulihan ini memerlukan kehati-hatian yang tinggi. Jika seluruh domain dipulihkan secara otoritatif dan cadangan sudah lama , ada risiko kehilangan perubahan sah yang dilakukan setelah pencadangan (misalnya, pembuatan pengguna, perubahan kata sandi, atau modifikasi grup). Oleh karena itu, praktik umum adalah membatasi pemulihan otoritatif hanya pada objek atau struktur data yang benar-benar diperlukan.

Pemulihan dan perbaikan SYSVOL (FRS vs DFSR)

SYSVOL adalah komponen kunci dari pengendali domain: ia menyimpan skrip startup, kebijakan grup, templat keamanan, dan sumber daya bersama penting lainnya . Kegagalan dalam izinnya, kerusakan file, atau masalah replikasi dapat membuat GPO tidak dapat digunakan atau menyebabkan perilaku yang tidak menentu pada klien.

Tergantung pada versi Windows Server dan status migrasi, SYSVOL dapat direplikasi oleh FRS (File Replication Service) atau DFSR (Distributed File System Replication) . Prosedur untuk pemulihan SYSVOL otoritatif bervariasi tergantung pada mana dari keduanya yang digunakan.

Untuk menentukan hal ini, Anda dapat memeriksa kunci Registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState . Jika subkunci ini ada dan nilainya adalah 3 (DELETED), DFSR sedang digunakan. Jika tidak ada atau nilainya berbeda, lingkungan tersebut masih menggunakan FRS.

Dalam lingkungan dengan FRS, pemulihan SYSVOL yang otoritatif biasanya melibatkan penyesuaian nilai. Burflags en HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process ke nilai tertentu (misalnya, 212 desimal / 0xD4 heksadesimal) untuk menunjukkan bahwa DC ini adalah sumber yang berwenang.

Jika SYSVOL direplikasi oleh DFSR, prosesnya agak lebih rumit: melibatkan penggunaan ADSIEdit untuk memodifikasi objek langganan SYSVOL ( atribut msDFSR-Enabled dan msDFSR-Options ) pada DC otoritatif dan yang lainnya, memaksa replikasi AD, menjalankan dfsrdiag pollad , dan mengkonfirmasi dalam log peristiwa munculnya peristiwa 4114, 4602, 4614, dan 4604 , yang menyatakan bahwa SYSVOL telah berhasil diinisialisasi dan direplikasi.

Memulihkan pengendali domain virtual dari VHD

Dalam lingkungan virtualisasi, sangat umum untuk memiliki file VHD/VHDX dari pengendali domain . Jika Anda tidak memiliki cadangan status sistem tetapi memiliki VHD "lama" yang berfungsi, Anda dapat memasang DC baru dari disk tersebut, meskipun Anda harus melakukannya dengan sangat hati-hati untuk menghindari terjadinya rollback USN.

Rekomendasinya adalah Jangan jalankan VM tersebut secara langsung dalam mode normal.Sebaliknya, Anda harus melakukan booting dari VHD sebelumnya di DSRMBuka Editor Registri dan navigasikan ke HKLM\SYSTEM\CurrentControlSet\Services\NTDS\ParametersDi sana, sebaiknya periksa nilainya. Jumlah restorasi DSA sebelumnya (jika ada) dan, yang terpenting, buat nilai DWORD (32-bit) baru yang disebut Basis data dipulihkan dari cadangan. dengan nilai 1

Dengan mengatur nilai ini, Active Directory diberi tahu bahwa basis data telah dipulihkan dari cadangan, yang memaksa pembuatan InvocationID baru saat startup normal . Hal ini memungkinkan pengendali domain lain untuk menginterpretasikannya sebagai instance baru dan menyesuaikan watermark replikasi mereka dengan benar, mencegah rollback USN.

Setelah memulai ulang DC dalam mode normal, periksa Event Viewer, khususnya log Directory Services , untuk event 1109. Event ini mengkonfirmasi bahwa atribut InvocationID server telah berubah dan menampilkan nilai lama dan baru, serta USN tertinggi pada saat pencadangan. Selain itu, nilai DSA Previous Restore Count seharusnya meningkat satu.

Jika kejadian-kejadian ini tidak muncul, atau jumlahnya tidak bertambah, Anda harus memeriksa versi sistem operasi dan Service Pack, karena perilaku pemulihan tertentu bergantung pada patch khusus . Bagaimanapun, selalu disarankan untuk mengerjakan salinan VHD asli, menyimpan versi yang utuh jika proses perlu diulang.

Skenario praktis dan rekomendasi tambahan

Dalam praktiknya, masalah korupsi atau restorasi yang tidak tepat sering muncul dalam skenario sehari-hari: Modifikasi manual izin di SYSVOL, upaya untuk memperbarui templat ADMX/ADML, perubahan GPO yang tidak direplikasi.dll. Relatif mudah untuk menyebabkan inkonsistensi jika folder bersama dimodifikasi secara manual, seperti SYSVOL\Policies tanpa menghormati replikasi.

Dalam kasus pengendali domain utama dengan replikasi yang rusak (baik data AD maupun SYSVOL) dan pesan pemantauan seperti “ Basis data dipulihkan menggunakan prosedur yang tidak didukung. Kemungkinan penyebab: Rollback USN ,” tindakan yang bijaksana adalah:

• Periksa dengan dcdiag y admin ulang sejauh mana kesalahan tersebut dan apakah ada "objek persisten".
• Periksa kejadian 2095 dan nilainya Dsa Tidak Dapat Ditulis di Registri.
• Nilai apakah hal itu memungkinkan hapus DC itu dan bangun ulang (Jika terdapat tiga atau lebih DC sehat lainnya, ini biasanya merupakan pilihan terbaik).
• Jika itu satu-satunya DC atau kritikus, angkat tangan. pemulihan keadaan sistem dari cadangan yang kompatibel, idealnya yang terbaru dan dalam periode tombstone.

Pada domain dengan beberapa pengendali domain, sangat disarankan agar pengendali domain sebersih mungkin: tanpa peran tambahan atau data pengguna lokal . Dengan cara ini, jika salah satu gagal atau rusak, pengendali domain tersebut dapat diformat dan yang baru dapat dipromosikan berdasarkan pengendali domain lain atau menggunakan Kerangka Kerja Manajemen Informasi (IMF), sehingga sangat mengurangi kompleksitas pemulihan.

Selain itu, penting untuk mengingat keterbatasan seperti fakta bahwa cadangan status sistem hanya berlaku selama periode tombstone (60, 90, atau 180 hari tergantung pada konfigurasi) untuk mencegah pemulihan objek yang telah dihapus, dan bahwa kunci komputer NTLM berubah setiap 7 hari. Untuk pemulihan yang sangat lama, mungkin perlu untuk mengatur ulang akun komputer yang bermasalah dari "Pengguna dan Komputer Direktori Aktif" atau bahkan menghapus dan menggabungkannya kembali ke domain.

Memiliki prosedur untuk secara teratur mencadangkan status sistem, mendokumentasikan peran FSMO, katalog global, dan topologi replikasi dengan jelas , serta sesekali menguji langkah-langkah pemulihan di lingkungan lab merupakan investasi waktu yang dapat menghemat banyak masalah ketika suatu saat pengendali domain mengalami kerusakan atau seseorang menerapkan snapshot tanpa berpikir panjang.