Kesalahan VPN Windows 691: pemeriksaan mana yang sebenarnya gagal?
Satu dialog mencakup beberapa penolakan yang berbeda. Periksa login literal, kredensial tersimpan, dan keputusan server sebelum mengatur ulang akun.
Windows menolak kata sandi yang diterimanya di tempat lain satu menit sebelumnya, sehingga akun tampak rusak padahal upaya itu tidak pernah dievaluasi. Kesalahan 691 berarti koneksi ditolak selama autentikasi, dan klien menampilkan teks yang sama baik rahasianya salah, nama akun terurai menjadi identitas yang tidak terduga, maupun kebijakan di sisi server menolak koneksi. Tiga perbaikan berbeda berbagi satu pesan, itulah sebabnya pengaturan ulang kadang membantu dan kadang tidak mengubah apa pun. Mulailah dari bagian yang bisa Anda periksa sendiri: string persis yang dikirim klien dan penyimpanan kredensial tempat ia mengambilnya. Lalu tanyakan kepada server keputusan mana yang dicatatnya, karena dialog itu adalah penolakan, bukan diagnosis.
Tiga cara ditolak, satu dialog
Rahasia yang salah hanyalah cara pertama untuk mencapai dialog ini. Nama akun dapat terurai menjadi identitas yang tidak Anda maksudkan, akun mungkin tidak memiliki izin dial-in, atau kondisi di server dapat menolak koneksi setelah kata sandi diterima. Masing-masing menghasilkan teks klien yang sama, dan masing-masing punya perbaikannya sendiri.
Itulah sebabnya pengaturan ulang tampak berhasil pada hari Senin dan tidak melakukan apa pun pada hari Selasa. Bacalah dialog itu sebagai penolakan, bukan diagnosis, dan catat nama profil serta waktu lokal kegagalan sebelum menyentuh akun.
Ketiga kategori juga gagal pada lapisan yang berbeda. Rahasia yang salah menggagalkan bukti identitas, bentuk akun yang salah menggagalkan pencarian, dan kondisi kebijakan menggagalkan otorisasi setelah identitas terbukti. Hanya yang pertama diperbaiki dengan mengganti kata sandi. Dua lainnya memerlukan seseorang yang memiliki akses ke catatan keputusan server, itulah sebabnya langkah berikutnya adalah permintaan informasi, bukan pengaturan ulang lagi.
Apa yang sebenarnya dikirim klien
Konfirmasikan format akun yang diterima dengan pihak yang menjalankan gateway, karena nama pengguna polos, nama berkualifikasi domain, dan nama utama pengguna dapat terurai ke konteks akun yang berbeda. Hanya satu di antaranya mungkin identitas yang memegang izin. Tanyakan format apa yang diharapkan gateway sebelum upaya pertama, bukan setelah yang kelima, dan periksa apakah klien menggunakan kembali kredensial tersimpan alih-alih yang Anda ketik.
Dua kueri hanya-baca di mesin Windows menunjukkan profil dan kredensial tersimpan di cache yang bisa mengalahkan dialog. Keduanya tidak menghubungi server:
Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatchPerlakukan kata sandi sebagai data, bukan sebagai teks yang disalin dari dokumen. Nilai yang melewati skrip mungkin membawa karakter escape yang tidak pernah menjadi bagian dari rahasia, dan ekspor konfigurasi mungkin telah mengapitnya dengan tanda kutip. Menghapus setiap karakter khusus agar cocok adalah perubahan yang berbeda dari menemukan nilai sebenarnya, jadi tetapkan dulu nilai sebenarnya.
Dapatkan keputusan kebijakan, bukan pengaturan ulang
Dalam penerapan akses jarak jauh yang menggunakan server kebijakan jaringan, dua keputusan berjalan berurutan. Autentikasi menetapkan akun mana yang bertanya, dan otorisasi memutuskan apakah akun itu boleh terhubung sama sekali. Kondisi dan batasan kebijakan dievaluasi menurut ukurannya sendiri, jadi rahasia yang benar hanya menyelesaikan separuh pertama pertanyaan. Nama kebijakan dalam peristiwa server menunjukkan keputusan mana yang benar-benar berjalan.
Kirimkan kepada administrator nama profil, akun yang dicoba, dan stempel waktu. Mintalah catatan keputusan yang cocok beserta alasannya alih-alih pengaturan ulang kata sandi lagi, dan mintalah nama kebijakan yang dibawa peristiwa tersebut. referensi kode kesalahan akses jarak jauh Microsoft mencantumkan 691 di antara kegagalan kredensial dan autentikasi, dan justru itulah sebabnya dialog tidak dapat memisahkan ketiga kasus.
Mengubah akun menjadi izin tanpa syarat mengubah keputusan otorisasi menjadi pengecualian permanen. Itu juga menghapus kondisi yang melakukan pekerjaan berguna, dan orang berikutnya yang meninjau kebijakan tidak akan tahu mengapa kebijakan itu berubah. Mintalah pemilik mengonfirmasi kebijakan yang dimaksudkan, agar penerimaan tetap disengaja.
Coba sekali lagi, lalu bandingkan
Ulangi profil yang sama setelah satu koreksi yang Anda identifikasi. Jika akses diterima dan sumber daya internal masih gagal, kegagalan telah berpindah ke lapisan lain dan tidak lagi mengatakan apa pun tentang kata sandi. Membiarkan profil tidak berubah itulah yang membuat perbandingan itu bermakna.
Tahan diri dari keinginan menonaktifkan keluarga alamat atau mengaktifkan pelacakan verbose sebelum penolakan dijelaskan. Pelacakan menghasilkan volume, bukan keputusan, dan hasil berguna pertama tetap komponen yang menolak upaya itu dan alasan yang dicatatnya. Setelah itu diketahui, upaya ulang entah menegaskan perbaikan atau menghasilkan gejala baru yang lebih sempit.