Windows VPN-fel 691: vilken kontroll misslyckades egentligen?

Windows avvisar ett lösenord som det accepterade någon annanstans en minut tidigare, så kontot ser trasigt ut trots att försöket aldrig utvärderades. Fel 691 betyder att anslutningen avvisades under autentiseringen, och klienten visar samma text oavsett om hemligheten var fel, om kontonamnet löstes upp till en oväntad identitet eller om en serverprincip avvisade anslutningen. Tre olika åtgärder delar ett enda meddelande, därför hjälper en återställning ibland och ändrar ibland ingenting alls. Börja med den del du kan undersöka själv: den exakta strängen som klienten skickade och det autentiseringsarkiv den hämtade den från. Fråga sedan servern vilket beslut den registrerade, eftersom dialogen är ett avvisande och inte en diagnos.

Tre sätt att bli avvisad, en enda dialog

En felaktig hemlighet är bara den första vägen till den här dialogen. Kontonamnet kan lösas upp till en identitet du inte avsåg, kontot kan sakna tillstånd för inringning, eller ett servervillkor kan avvisa anslutningen efter att lösenordet har accepterats. Varje sådant fall ger samma klienttext, och varje har sin egen åtgärd.

Därför ser en återställning ut att fungera på måndagen och gör ingenting på tisdagen. Läs dialogen som ett avvisande och inte som en diagnos, och notera profilnamnet och den lokala tiden för felet innan du rör kontot.

De tre kategorierna misslyckas också på olika lager. En felaktig hemlighet misslyckas i identitetsbeviset, en felaktig kontoform misslyckas i uppslaget, och ett principvillkor misslyckas i auktoriseringen efter att identiteten har bevisats. Bara den första åtgärdas genom att byta lösenord. De andra två kräver någon med tillgång till serverns beslutslogg, därför är nästa steg en informationsbegäran och inte ännu en återställning.

Vad klienten faktiskt skickade

Bekräfta det accepterade kontoformatet med den som driftar gatewayen, eftersom ett bart användarnamn, ett domänkvalificerat namn och ett huvudanvändarnamn kan lösas upp till olika kontokontexter. Bara ett av dem är möjligen identiteten som har behörigheten. Fråga vilken form gatewayen förväntar sig före det första försöket och inte efter det femte, och kontrollera om klienten återanvänder en sparad autentiseringsuppgift i stället för den du skrev in.

Två skrivskyddade frågor på Windows-datorn visar profilen och eventuella cachelagrade autentiseringsuppgifter som skulle kunna överrösta dialogen. Ingen av dem ringer servern:

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

Behandla lösenordet som data och inte som text kopierad från ett dokument. Ett värde som har gått genom ett skript kan bära escape-tecken som aldrig var en del av hemligheten, och en konfigurationsexport har kanske satt det inom citattecken. Att ta bort varje specialtecken för att det ska passa är en annan ändring än att hitta det verkliga värdet, så fastställ det verkliga värdet först.

Hämta principbeslutet, inte en återställning

I en fjärråtkomstinstallation som använder en nätverksprincipserver körs två beslut i följd. Autentiseringen fastställer vilket konto som frågar, och auktoriseringen avgör om det kontot överhuvudtaget får ansluta. Principvillkor och begränsningar utvärderas enligt sina egna kriterier, så en korrekt hemlighet avgör bara den första halvan av frågan. Principnamnet i serverhändelsen anger vilket beslut som faktiskt kördes.

Skicka profilnamnet, det försökta kontot och tidsstämpeln till administratören. Be om motsvarande beslutslogg och dess skäl i stället för ännu en lösenordsåterställning, och be om principnamnet som händelsen bär. Microsofts referens för felkoder vid fjärråtkomst listar 691 bland autentiserings- och verifieringsfel, och just därför kan dialogen inte skilja de tre fallen åt.

Att göra ett konto till ett ovillkorligt tillstånd gör ett auktoriseringsbeslut till ett permanent undantag. Det tar också bort villkoret som gjorde nytta, och nästa person som granskar principen vet inte varför den ändrades. Be i stället ägaren bekräfta den avsedda principen, så att acceptansen förblir medveten.

Försök en gång till och jämför sedan

Upprepa samma profil efter den enda korrigering du identifierade. Om åtkomst accepteras och en intern resurs fortfarande misslyckas, har felet flyttat till ett annat lager och säger inte längre något om lösenordet. Det är den oförändrade profilen som gör jämförelsen meningsfull.

Motstå frestelsen att inaktivera en adressfamilj eller slå på detaljerad spårning innan avvisandet har förklarats. Spårning ger volym och inte ett beslut, och det första användbara resultatet är fortfarande komponenten som avvisade försöket och skälet den registrerade. När det är känt bekräftar det nya försöket antingen åtgärden eller ger ett nytt och snävare symtom.