Windows VPN-fejl 691: hvilket tjek fejlede egentlig?

Windows afviser en adgangskode, som det accepterede et andet sted et minut tidligere, så kontoen ser i stykker ud, selvom forsøget aldrig blev vurderet. Fejl 691 betyder, at forbindelsen blev afvist under godkendelse, og klienten viser den samme tekst, uanset om hemmeligheden var forkert, om kontonavnet blev opløst til en uventet identitet, eller om en serverpolitik afviste forbindelsen. Tre forskellige rettelser deler én meddelelse, og derfor hjælper en nulstilling nogle gange og ændrer andre gange ingenting. Start med den del, du selv kan undersøge: den præcise streng, klienten sendte, og det legitimationslager, den tog den fra. Spørg derefter serveren, hvilken beslutning den registrerede, fordi dialogen er en afvisning og ikke en diagnose.

Tre måder at blive afvist på, én dialog

En forkert hemmelighed er kun den første vej til denne dialog. Kontonavnet kan opløses til en identitet, du ikke havde tænkt på, kontoen har måske ingen tilladelse til fjernadgang, eller en serverbetingelse kan afvise forbindelsen, efter at adgangskoden er accepteret. Hvert af disse tilfælde giver den samme klienttekst, og hvert har sin egen rettelse.

Derfor ser en nulstilling ud til at virke om mandagen og gør ingenting om tirsdagen. Læs dialogen som en afvisning snarere end en diagnose, og noter profilnavnet og det lokale tidspunkt for fejlen, før du rører kontoen.

De tre kategorier fejler også på forskellige lag. En forkert hemmelighed fejler identitetsbeviset, en forkert kontoform fejler opslaget, og en politikbetingelse fejler autorisationen, efter at identiteten er bevist. Kun den første rettes ved at skifte adgangskode. De to andre kræver nogen med adgang til serverens beslutningslog, og derfor er næste skridt en anmodning om oplysninger og ikke endnu en nulstilling.

Hvad klienten faktisk sendte

Bekræft det accepterede kontoformat med den, der driver gatewayen, fordi et bart brugernavn, et domænekvalificeret navn og et hovedbrugerprincip kan føre til forskellige kontokontekster. Kun ét af dem kan være den identitet, der har tilladelsen. Spørg, hvilken form gatewayen forventer, før det første forsøg og ikke efter det femte, og kontroller, om klienten genbruger en gemt legitimationsoplysning i stedet for den, du indtastede.

To skrivebeskyttede forespørgsler på Windows-maskinen viser profilen og eventuelle cachelagrede legitimationsoplysninger, der kan overtrumfe dialogen. Ingen af dem ringer til serveren:

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

Behandl adgangskoden som data og ikke som tekst kopieret fra et dokument. En værdi, der har været gennem et script, kan bære escape-tegn, der aldrig var en del af hemmeligheden, og en konfigurationseksport har måske sat den i anførselstegn. At fjerne hvert specialtegn for at få den til at passe er en anden ændring end at finde den rigtige værdi, så fastlæg den rigtige værdi først.

Hent politikbeslutningen, ikke en nulstilling

I en fjernadgangsinstallation, der bruger en netværkspolicyserver, kører to beslutninger i rækkefølge. Godkendelse fastslår, hvilken konto der spørger, og autorisation afgør, om den konto overhovedet må forbinde. Politikbetingelser og -begrænsninger vurderes på deres egne vilkår, så en korrekt hemmelighed afgør kun den første halvdel af spørgsmålet. Politiknavnet i serverhændelsen angiver, hvilken beslutning der faktisk kørte.

Send administratoren profilnavnet, den forsøgte konto og tidsstemplet. Bed om den tilsvarende beslutningslog og dens begrundelse i stedet for endnu en nulstilling af adgangskoden, og bed om det politiknavn, som hændelsen bærer. Microsofts reference for fejlkoder til fjernadgang opfører 691 blandt legitimations- og godkendelsesfejlene, og netop derfor kan dialogen ikke skelne de tre tilfælde.

At konvertere en konto til en ubetinget tilladelse gør en autorisationsbeslutning til en permanent undtagelse. Det fjerner også den betingelse, der gjorde nytte, og den næste, der gennemgår politikken, ved ikke, hvorfor den blev ændret. Lad i stedet ejeren bekræfte den tilsigtede politik, så accepten forbliver bevidst.

Prøv én gang til, og sammenlign derefter

Gentag den samme profil efter den ene rettelse, du identificerede. Hvis adgang accepteres, og en intern ressource stadig fejler, er fejlen flyttet til et andet lag og siger ikke længere noget om adgangskoden. Det er den uændrede profil, der gør sammenligningen meningsfuld.

Modstå fristelsen til at deaktivere en adressefamilie eller aktivere detaljeret sporing, før afvisningen er forklaret. Sporing giver volumen og ikke en beslutning, og det første nyttige resultat er fortsat den komponent, der afviste forsøget, og den begrundelse, den registrerede. Når det er kendt, bekræfter gentagelsen enten rettelsen eller giver et nyt og snævrere symptom.