Eroarea 691 VPN în Windows: care verificare a eșuat de fapt?

Windows refuză o parolă pe care a acceptat-o în altă parte cu un minut înainte, așa că respectivul cont pare defect chiar dacă încercarea nu a fost niciodată evaluată. Eroarea 691 înseamnă că conexiunea a fost refuzată în timpul autentificării, iar clientul afișează același text fie că secretul era greșit, fie că numele contului s-a rezolvat într-o identitate neașteptată, fie că o politică de pe server a refuzat conexiunea. Trei reparații diferite împart un singur mesaj, de aceea o resetare ajută uneori și alteori nu schimbă absolut nimic. Începeți cu partea pe care o puteți inspecta singur: șirul exact trimis de client și depozitul de acreditări din care l-a luat. Apoi întrebați serverul ce decizie a înregistrat, pentru că dialogul este un refuz, nu un diagnostic.

Trei moduri de a fi refuzat, un singur dialog

Un secret greșit este doar primul mod de a ajunge la acest dialog. Numele contului se poate rezolva într-o identitate pe care nu o intenționați, contul poate să nu aibă permisiune de apelare sau o condiție de pe server poate refuza conexiunea după ce parola este acceptată. Fiecare dintre aceste cazuri produce același text în client, iar fiecare are propria reparație.

De aceea o resetare pare să funcționeze luni și nu face nimic marți. Citiți dialogul ca pe un refuz, nu ca pe un diagnostic, și notați numele profilului și ora locală a eșecului înainte de a atinge contul.

Cele trei categorii eșuează și pe straturi diferite. Un secret greșit eșuează proba identității, o formă greșită a contului eșuează căutarea, iar o condiție de politică eșuează autorizarea după ce identitatea este dovedită. Doar prima se repară schimbând parola. Celelalte două au nevoie de cineva cu acces la registrul de decizii al serverului, de aceea pasul următor este o cerere de informații, nu o altă resetare.

Ce a trimis de fapt clientul

Confirmați formatul de cont acceptat cu cel care administrează poarta de acces, deoarece un nume de utilizator simplu, un nume calificat de domeniu și un nume principal de utilizator pot duce la contexte de cont diferite. Doar unul dintre ele poate fi identitatea care deține permisiunea. Întrebați ce formă așteaptă poarta înainte de prima încercare, nu după a cincea, și verificați dacă clientul refolosește o acreditare stocată în locul celei tastate.

Două interogări doar în citire pe mașina Windows arată profilul și orice acreditare din cache care ar putea învinge dialogul. Niciuna nu apelează serverul:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

Tratați parola ca date, nu ca text copiat dintr-un document. O valoare care a trecut printr-un script poate purta caractere de evacuare care nu au făcut niciodată parte din secret, iar un export de configurație a pus-o poate între ghilimele. Eliminarea fiecărui caracter special ca să se potrivească este o modificare diferită de găsirea valorii reale, așa că stabiliți mai întâi valoarea reală.

Obțineți decizia politicii, nu o resetare

Într-o implementare de acces la distanță care folosește un server de politici de rețea, două decizii rulează în succesiune. Autentificarea stabilește ce cont întreabă, iar autorizarea decide dacă acel cont se poate conecta măcar. Condițiile și constrângerile politicii sunt evaluate după propriile criterii, așa că un secret corect rezolvă doar prima jumătate a întrebării. Numele politicii din evenimentul serverului indică ce decizie a rulat de fapt.

Trimiteți administratorului numele profilului, contul încercat și marca temporală. Cereți înregistrarea deciziei corespunzătoare și motivul ei în loc de o altă resetare a parolei și cereți numele politicii pe care o poartă evenimentul. referința codurilor de eroare pentru accesul la distanță de la Microsoft enumeră 691 printre eșecurile de acreditare și autentificare, și exact de aceea dialogul nu poate separa cele trei cazuri.

Transformarea unui cont într-o permisiune necondiționată transformă o decizie de autorizare într-o excepție permanentă. Elimină și condiția care făcea o muncă utilă, iar următoarea persoană care va revizui politica nu va ști de ce s-a schimbat. Cereți în schimb proprietarului să confirme politica dorită, ca acceptarea să rămână deliberată.

Încercați încă o dată, apoi comparați

Repetați același profil după singura corecție pe care ați identificat-o. Dacă accesul este acceptat și o resursă internă încă eșuează, eșecul s-a mutat pe alt strat și nu mai spune nimic despre parolă. Profilul neschimbat este ceea ce face comparația semnificativă.

Rezistați tentației de a dezactiva o familie de adrese sau de a activa urmărirea detaliată înainte ca refuzul să fie explicat. Urmărirea produce volum, nu o decizie, iar primul rezultat util rămâne componenta care a refuzat încercarea și motivul pe care l-a înregistrat. Odată știut acest lucru, noua încercare confirmă reparația sau produce un simptom nou și mai îngust.