Ralat VPN Windows 691: pemeriksaan mana yang sebenarnya gagal?
Satu dialog merangkumi beberapa penolakan berbeza. Semak log masuk literal, kelayakan tersimpan dan keputusan pelayan sebelum menetapkan semula akaun.
Windows menolak kata laluan yang diterimanya di tempat lain seminit lebih awal, jadi akaun kelihatan rosak sedangkan percubaan itu tidak pernah dinilai. Ralat 691 bermaksud sambungan ditolak semasa pengesahan, dan klien memaparkan teks yang sama sama ada rahsia itu salah, nama akaun diselesaikan kepada identiti yang tidak dijangka, atau dasar di pihak pelayan menolak sambungan. Tiga pembaikan berbeza berkongsi satu mesej, itulah sebabnya penetapan semula kadang-kadang membantu dan kadang-kadang tidak mengubah apa-apa. Mulakan dengan bahagian yang anda boleh periksa sendiri: rentetan tepat yang dihantar oleh klien dan stor kelayakan tempat ia mengambilnya. Kemudian tanya pelayan keputusan mana yang dicatatkannya, kerana dialog itu ialah penolakan, bukan diagnosis.
Tiga cara ditolak, satu dialog
Rahsia yang salah hanyalah cara pertama untuk sampai ke dialog ini. Nama akaun boleh diselesaikan kepada identiti yang tidak anda maksudkan, akaun mungkin tidak mempunyai kebenaran dail masuk, atau syarat di pelayan boleh menolak sambungan selepas kata laluan diterima. Setiap satu daripadanya menghasilkan teks klien yang sama, dan setiap satu mempunyai pembaikannya sendiri.
Itulah sebabnya penetapan semula kelihatan berkesan pada hari Isnin dan tidak melakukan apa-apa pada hari Selasa. Baca dialog itu sebagai penolakan dan bukan diagnosis, dan catat nama profil serta masa setempat kegagalan sebelum menyentuh akaun.
Ketiga-tiga kategori juga gagal pada lapisan yang berbeza. Rahsia yang salah menggagalkan bukti identiti, bentuk akaun yang salah menggagalkan carian, dan syarat dasar menggagalkan kebenaran selepas identiti dibuktikan. Hanya yang pertama dibaiki dengan menukar kata laluan. Dua lagi memerlukan seseorang yang mempunyai akses kepada rekod keputusan pelayan, itulah sebabnya langkah seterusnya ialah permintaan maklumat, bukan penetapan semula lagi.
Apa yang sebenarnya dihantar oleh klien
Sahkan format akaun yang diterima dengan pihak yang mengendalikan get laluan, kerana nama pengguna kosong, nama berkelayakan domain dan nama prinsipal pengguna boleh diselesaikan kepada konteks akaun yang berbeza. Hanya satu daripadanya mungkin identiti yang memegang kebenaran. Tanya format apa yang dijangka oleh get laluan sebelum percubaan pertama dan bukan selepas yang kelima, dan semak sama ada klien menggunakan semula kelayakan tersimpan dan bukannya yang anda taip.
Dua pertanyaan baca sahaja pada mesin Windows menunjukkan profil dan sebarang kelayakan cache yang boleh mengalahkan dialog. Kedua-duanya tidak mendail pelayan:
Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatchAnggap kata laluan sebagai data dan bukan teks yang disalin daripada dokumen. Nilai yang melalui skrip mungkin membawa aksara escape yang tidak pernah menjadi bahagian rahsia, dan eksport konfigurasi mungkin telah meletakkannya dalam tanda petik. Membuang setiap aksara khas supaya ia sepadan ialah perubahan yang berbeza daripada mencari nilai sebenar, jadi tetapkan dahulu nilai sebenar.
Dapatkan keputusan dasar, bukan penetapan semula
Dalam penggunaan akses jauh yang menggunakan pelayan dasar rangkaian, dua keputusan berjalan berturutan. Pengesahan menetapkan akaun mana yang bertanya, dan kebenaran memutuskan sama ada akaun itu boleh bersambung sama sekali. Syarat dan kekangan dasar dinilai mengikut ukurannya sendiri, jadi rahsia yang betul hanya menyelesaikan separuh pertama soalan. Nama dasar dalam peristiwa pelayan menunjukkan keputusan mana yang benar-benar berjalan.
Hantar kepada pentadbir nama profil, akaun yang dicuba dan cap masa. Minta rekod keputusan yang sepadan dan alasannya dan bukannya penetapan semula kata laluan lagi, dan minta nama dasar yang dibawa oleh peristiwa itu. rujukan kod ralat akses jauh Microsoft menyenaraikan 691 antara kegagalan kelayakan dan pengesahan, dan itulah sebabnya dialog tidak dapat memisahkan ketiga-tiga kes.
Menukar akaun kepada kebenaran tanpa syarat menjadikan keputusan kebenaran sebagai pengecualian kekal. Ia juga membuang syarat yang melakukan kerja berguna, dan orang seterusnya yang menyemak dasar itu tidak akan tahu mengapa ia berubah. Minta pemilik mengesahkan dasar yang dimaksudkan, supaya penerimaan kekal disengajakan.
Cuba sekali lagi, kemudian bandingkan
Ulangi profil yang sama selepas satu-satunya pembetulan yang anda kenal pasti. Jika akses diterima dan sesetengah sumber dalaman masih gagal, kegagalan telah berpindah ke lapisan lain dan tidak lagi berkata apa-apa tentang kata laluan. Membiarkan profil tidak berubah itulah yang menjadikan perbandingan itu bermakna.
Tahan diri daripada keinginan untuk melumpuhkan keluarga alamat atau mengaktifkan surih terperinci sebelum penolakan dijelaskan. Surih menghasilkan isipadu dan bukan keputusan, dan hasil berguna pertama kekal sebagai komponen yang menolak percubaan itu dan sebab yang dicatatkannya. Setelah itu diketahui, percubaan semula sama ada mengesahkan pembaikan atau menghasilkan gejala baharu yang lebih sempit.