Windows VPN-fout 691: welke controle is werkelijk mislukt?
Eén dialoogvenster dekt meerdere verschillende weigeringen. Controleer de letterlijke aanmelding, de opgeslagen referentie en de beslissing van de server voordat u een account opnieuw instelt.
Windows weigert een wachtwoord dat het een minuut eerder elders accepteerde, waardoor het account stuk lijkt terwijl de poging nooit is beoordeeld. Fout 691 betekent dat de verbinding tijdens de verificatie is geweigerd, en de client toont dezelfde tekst of het geheim nu onjuist was, de accountnaam naar een onverwachte identiteit is omgezet, of een beleid aan de serverkant de verbinding heeft geweigerd. Drie verschillende reparaties delen één bericht, daarom helpt een herstel soms en verandert het soms helemaal niets. Begin met het deel dat u alleen kunt onderzoeken: de exacte tekenreeks die de client heeft verzonden en het referentiearchief waaruit hij die heeft gehaald. Vraag de server daarna welke beslissing hij heeft vastgelegd, want het dialoogvenster is een weigering en geen diagnose.
Drie manieren om geweigerd te worden, één dialoogvenster
Een onjuist geheim is slechts de eerste weg naar dit dialoogvenster. De accountnaam kan naar een identiteit worden omgezet die u niet bedoelde, het account heeft mogelijk geen inbelmachtiging, of een servervoorwaarde kan de verbinding weigeren nadat het wachtwoord is geaccepteerd. Elk van die gevallen levert dezelfde clienttekst op, en elk heeft zijn eigen reparatie.
Daarom lijkt een herstel op maandag te werken en doet het op dinsdag niets. Lees het dialoogvenster als een weigering en niet als een diagnose, en noteer de profielnaam en de lokale tijd van de fout voordat u het account aanraakt.
De drie categorieën falen ook op verschillende lagen. Een onjuist geheim laat het identiteitsbewijs falen, een onjuiste accountvorm laat de opzoeking falen, en een beleidsvoorwaarde laat de autorisatie falen nadat de identiteit is bewezen. Alleen de eerste wordt gerepareerd door het wachtwoord te wijzigen. De andere twee vereisen iemand met toegang tot het beslissingsregister van de server, daarom is de volgende stap een informatieverzoek en geen nieuw herstel.
Wat de client werkelijk heeft verzonden
Bevestig de geaccepteerde accountindeling met degene die de gateway beheert, want een kale gebruikersnaam, een domeingekwalificeerde naam en een hoofdgebruikersnaam kunnen naar verschillende accountcontexten worden omgezet. Slechts één daarvan is mogelijk de identiteit met de machtiging. Vraag vóór de eerste poging en niet na de vijfde welke vorm de gateway verwacht, en controleer of de client een opgeslagen referentie hergebruikt in plaats van degene die u hebt getypt.
Twee alleen-lezen-query's op de Windows-machine tonen het profiel en eventuele in de cache opgeslagen referenties die het dialoogvenster kunnen overstemmen. Geen van beide belt de server:
Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatchBehandel het wachtwoord als gegevens en niet als tekst die uit een document is gekopieerd. Een waarde die door een script is gegaan, kan escape-tekens bevatten die nooit deel van het geheim waren, en een configuratie-export heeft er misschien aanhalingstekens omheen gezet. Elk speciaal teken verwijderen om het passend te maken is een andere wijziging dan de echte waarde vinden, dus stel eerst de echte waarde vast.
Haal de beleidsbeslissing op, geen herstel
Bij een implementatie voor externe toegang met een netwerkbeleidsserver worden twee beslissingen na elkaar uitgevoerd. Verificatie stelt vast welk account het vraagt, en autorisatie bepaalt of dat account überhaupt mag verbinden. Beleidsvoorwaarden en -beperkingen worden volgens hun eigen maatstaven beoordeeld, dus een juist geheim beslecht slechts de eerste helft van de vraag. De beleidsnaam in de servergebeurtenis geeft aan welke beslissing werkelijk is uitgevoerd.
Stuur de beheerder de profielnaam, het geprobeerde account en de tijdstempel. Vraag om het bijbehorende beslissingsregister en de reden daarvan in plaats van nog een wachtwoordherstel, en vraag om de beleidsnaam die de gebeurtenis draagt. Microsofts referentiegids voor foutcodes bij externe toegang vermeldt 691 onder de referentie- en verificatiefouten, en precies daarom kan het dialoogvenster de drie gevallen niet onderscheiden.
Een account omzetten in een onvoorwaardelijke toestemming maakt van een autorisatiebeslissing een permanente uitzondering. Het verwijdert ook de voorwaarde die nuttig werk deed, en de volgende persoon die het beleid beoordeelt, weet niet waarom het is gewijzigd. Laat de eigenaar in plaats daarvan het bedoelde beleid bevestigen, zodat de acceptatie bewust blijft.
Probeer het nog één keer en vergelijk daarna
Herhaal hetzelfde profiel na de enige correctie die u hebt vastgesteld. Als toegang wordt geaccepteerd en een interne bron mislukt nog steeds, is de fout naar een andere laag verhuisd en zegt hij niets meer over het wachtwoord. Het ongewijzigde profiel is wat die vergelijking zinvol maakt.
Weersta de verleiding om een adresfamilie uit te schakelen of uitgebreide tracering in te schakelen voordat de weigering is uitgelegd. Tracering levert volume op en geen beslissing, en het eerste nuttige resultaat blijft het onderdeel dat de poging heeft geweigerd en de reden die het heeft vastgelegd. Als dat bekend is, bevestigt de nieuwe poging de reparatie of levert hij een nieuw en smaller symptoom op.