Windows VPN-feil 691: hvilken kontroll mislyktes egentlig?

Windows avviser et passord som det godtok et annet sted et minutt tidligere, så kontoen ser ødelagt ut selv om forsøket aldri ble vurdert. Feil 691 betyr at tilkoblingen ble avvist under autentiseringen, og klienten viser den samme teksten enten hemmeligheten var feil, kontonavnet ble løst til en uventet identitet, eller en serverpolitikk avviste tilkoblingen. Tre forskjellige reparasjoner deler én melding, og derfor hjelper en tilbakestilling noen ganger og endrer andre ganger ingenting i det hele tatt. Begynn med delen du kan undersøke selv: den nøyaktige strengen klienten sendte, og legitimasjonslageret den hentet den fra. Spør deretter serveren hvilken beslutning den registrerte, fordi dialogen er en avvisning og ikke en diagnose.

Tre måter å bli avvist på, én dialog

En feil hemmelighet er bare den første veien til denne dialogen. Kontonavnet kan løses til en identitet du ikke hadde tenkt på, kontoen kan mangle tillatelse til innringing, eller en serverbetingelse kan avvise tilkoblingen etter at passordet er godtatt. Hvert av disse tilfellene gir den samme klientteksten, og hvert har sin egen reparasjon.

Derfor ser en tilbakestilling ut til å virke på mandag og gjør ingenting på tirsdag. Les dialogen som en avvisning og ikke som en diagnose, og noter profilnavnet og det lokale tidspunktet for feilen før du berører kontoen.

De tre kategoriene mislykkes også på forskjellige lag. En feil hemmelighet mislykkes i identitetsbeviset, en feil kontoform mislykkes i oppslaget, og en politikbetingelse mislykkes i autorisasjonen etter at identiteten er bevist. Bare den første repareres ved å bytte passord. De to andre krever noen med tilgang til serverens beslutningslogg, og derfor er neste steg en informasjonsforespørsel og ikke en ny tilbakestilling.

Hva klienten faktisk sendte

Bekreft det godtatte kontoformatet med den som drifter gatewayen, fordi et bart brukernavn, et domenekvalifisert navn og et hovedbrukernavn kan løses til forskjellige kontokontekster. Bare ett av dem er kanskje identiteten som har tillatelsen. Spør hvilken form gatewayen forventer før det første forsøket og ikke etter det femte, og kontroller om klienten gjenbruker en lagret legitimasjon i stedet for den du skrev inn.

To skrivebeskyttede spørringer på Windows-maskinen viser profilen og eventuell bufret legitimasjon som kan overstyre dialogen. Ingen av dem ringer serveren:

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

Behandle passordet som data og ikke som tekst kopiert fra et dokument. En verdi som har gått gjennom et skript kan bære escape-tegn som aldri var en del av hemmeligheten, og en konfigurasjonseksport har kanskje satt den i anførselstegn. Å fjerne hvert spesialtegn for at det skal passe er en annen endring enn å finne den virkelige verdien, så fastslå den virkelige verdien først.

Hent politikbeslutningen, ikke en tilbakestilling

I en fjernaksessutplassering som bruker en nettverkspolicyserver, kjøres to beslutninger etter hverandre. Autentisering fastslår hvilken konto som spør, og autorisasjon avgjør om den kontoen i det hele tatt får koble til. Politikbetingelser og -begrensninger vurderes etter egne kriterier, så en korrekt hemmelighet avgjør bare den første halvdelen av spørsmålet. Politiknavnet i serverhendelsen angir hvilken beslutning som faktisk kjørtes.

Send administratoren profilnavnet, den forsøkte kontoen og tidsstemplet. Be om den tilhørende beslutningsloggen og begrunnelsen i stedet for nok en passordtilbakestilling, og be om politiknavnet som hendelsen bærer. Microsofts referanse for feilkoder ved fjernaksess fører opp 691 blant legitimasjons- og autentiseringsfeilene, og nettopp derfor kan dialogen ikke skille de tre tilfellene.

Å gjøre en konto om til en ubetinget tillatelse gjør en autorisasjonsbeslutning til et permanent unntak. Det fjerner også betingelsen som gjorde nytte, og den neste som gjennomgår politikken vil ikke vite hvorfor den ble endret. Be i stedet eieren bekrefte den tiltenkte politikken, slik at aksepten forblir bevisst.

Prøv én gang til, og sammenlign deretter

Gjenta samme profil etter den ene korreksjonen du identifiserte. Hvis tilgang godtas og en intern ressurs fortsatt feiler, har feilen flyttet til et annet lag og sier ikke lenger noe om passordet. Det er den uendrede profilen som gjør sammenligningen meningsfull.

Motstå fristelsen til å deaktivere en adressefamilie eller slå på detaljert sporing før avvisningen er forklart. Sporing gir volum og ikke en beslutning, og det første nyttige resultatet er fortsatt komponenten som avviste forsøket, og begrunnelsen den registrerte. Når det er kjent, bekrefter det nye forsøket enten reparasjonen eller gir et nytt og snevrere symptom.