Kepercayaan domain gagal setelah sebulan offline? Periksa dulu

Sebuah laptop berada di luar VPN selama enam minggu, kembali, dan pengguna tidak dapat masuk dengan akun domain. Kesalahan menyebut hubungan kepercayaan, sehingga seseorang mengatur ulang akun komputer, atau memaksa pengguna ke tunneling penuh, dan masalahnya tampak hilang. Tidak satu pun tindakan itu membuktikan apa yang rusak. Anggota Windows dapat tetap offline jauh melewati interval kata sandi mesin yang biasa tanpa kehilangan kepercayaan secara otomatis, jadi tugas pertama adalah memisahkan kegagalan keterjangkauan dari ketidakcocokan rahasia yang sebenarnya.

Kesalahannya tampak seperti kepercayaan, tetapi tiga keadaan mirip

Pengguna mungkin masuk dengan informasi domain yang di-cache, stasiun kerja mungkin tidak dapat menemukan pengontrol domain, atau anggota dan domain benar-benar berselisih tentang akun komputer. Hanya yang ketiga merupakan hubungan kepercayaan yang rusak dalam arti ketat.

Kesehatan replikasi AD adalah pengamatan keempat, dan sama sekali bukan tentang stasiun kerja ini. Ini menggambarkan kesepakatan antar pengontrol domain, dan dasbor replikasi yang sehat tidak membuktikan bahwa rahasia lokal mesin ini cocok dengan akun komputernya.

Standar 30 hari yang lazim adalah kebijakan perubahan, bukan tenggat kedaluwarsa offline. Penjelasan Microsoft tentang kata sandi akun mesin menggambarkan proses perubahan terkoordinasi, dan organisasi dapat mengonfigurasi interval berbeda.

Ikon VPN tidak membuktikan apa pun tentang kanal aman

Konektivitas harus cukup baik untuk mencapai layanan domain sebelum tes apa pun berarti. Itu berarti resolver DNS domain yang dimaksud, pengontrol yang dapat ditemukan, layanan autentikasi yang dapat dijangkau, dan jam yang cukup dekat untuk Kerberos.

Tunneling penuh bisa menjadi desain yang sepenuhnya sah di sini. Berpindah ke split tunneling bukan prasyarat hubungan domain yang sehat, dan memperlakukannya sebagai prasyarat mengubah diagnosis menjadi perubahan arsitektur. Periksa pengontrol mana yang benar-benar dipilih stasiun kerja, dan simpan nama itu bersama kesalahan.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Catat server DNS, pengontrol yang di-resolve, dan teks kesalahan yang tepat. Klien VPN yang melaporkan terhubung memberi tahu Anda bahwa terowongan ada, bukan bahwa jalur domain berfungsi. Pengontrol yang menjawab pada port Kerberos tetapi tidak pada port direktori adalah temuan firewall, bukan temuan kepercayaan.

Uji anggota sebelum memperbaikinya

Pada anggota domain Windows yang sah, Test-ComputerSecureChannel -Verbose adalah pemeriksaan hanya-baca atas kanal antara mesin dan domain. Jalankan dalam konteks mesin yang Anda selidiki, bukan dari pengontrol domain, yang memiliki peran dan aturan pemulihan berbeda. Rekam keluaran dan status keluarnya, bukan kata lulus atau gagal. Jika cmdlet tidak ada pada build itu, modul adalah masalah terpisah.

Hasilnya masih membutuhkan konteks. Jika mesin tidak dapat menjangkau atau mengautentikasi ke pengontrol yang dipilih, tes yang gagal bukan bukti independen bahwa kata sandi offline telah kedaluwarsa. Simpan kesalahan sebenarnya dan pengontrol yang digunakan, dan ulangi tes setelah jalur diketahui baik.

Korelasikan peristiwa Netlogon pada anggota dan pada pengontrol terkait di sekitar insiden. Simpan nama mesin, alamat sumber, waktu, dan bukti perubahan akun apa pun. Login berhasil pengguna lain, atau dasbor pengontrol yang sehat, tidak dapat menggantikan pertukaran mesin ini.

Perbaiki hanya hubungan yang telah Anda buktikan

Setelah konektivitas stabil dan administrator mengonfirmasi bahwa perbaikan sesuai, mode -Repair dari cmdlet dengan kredensial resmi adalah salah satu operasi yang didukung untuk stasiun kerja anggota. Ini mengubah hubungan, dan bukan tes hanya-baca lainnya.

Siapkan akun pemulihan lokal yang disetujui dan jalur manajemen sebelum perubahan. Pengontrol domain memiliki peran pemulihan berbeda dan tidak boleh diperlakukan sebagai stasiun kerja biasa oleh prosedur ini. Gunakan alur kerja pemulihan organisasi alih-alih menjalankan beberapa alat pengaturan ulang secara berurutan dan berharap salah satunya yang benar.

Setelah perbaikan, verifikasi tes kanal aman yang baru dan operasi domain asli. Pertahankan profil pengguna dan status aplikasi, dan jangan jadikan lepas-dan-gabung-ulang sebagai tindakan pertama yang tak dijelaskan.

Apa yang harus diperiksa saat kegagalan kembali

Jika kegagalan kembali, lihat rollback, identitas ganda, dan waktu perubahan akun alih-alih mengatur ulang akun yang sama lagi. Image yang dipulihkan, snapshot, identitas mesin yang dikloning, atau pengaturan ulang akun komputer yang dilakukan di tempat lain semuanya layak diselidiki.

Pengaturan ulang yang berhasil sementara adalah bukti pemulihan yang berguna, tetapi bukan bukti bahwa VPN intermiten menyebabkan ketidakcocokan asli. Kemunculan berikutnya-lah yang memberi tahu Anda apakah penyebabnya pernah dihilangkan.

Tulis pengontrol, server DNS, dan keluaran tes ke dalam tiket. Catatan itulah yang membedakan kegagalan kepercayaan nyata dari laptop yang sekadar tidak dapat menemukan domain.