Windows VPN-Fehler 691: Welche Prüfung ist wirklich fehlgeschlagen?

Windows lehnt ein Kennwort ab, das es eine Minute zuvor anderswo akzeptiert hat, sodass das Konto defekt wirkt, obwohl der Versuch nie ausgewertet wurde. Fehler 691 bedeutet, dass die Verbindung während der Authentifizierung abgelehnt wurde, und der Client zeigt denselben Text, ob das Geheimnis falsch war, ob der Kontoname in eine unerwartete Identität aufgelöst wurde oder ob eine serverseitige Richtlinie die Verbindung verweigerte. Drei verschiedene Reparaturen teilen sich eine Meldung, deshalb hilft ein Zurücksetzen manchmal und ändert manchmal gar nichts. Beginnen Sie mit dem Teil, den Sie allein prüfen können: der genauen Zeichenfolge, die der Client übermittelt hat, und dem Anmeldeinformationsspeicher, aus dem er sie bezogen hat. Fragen Sie dann den Server, welche Entscheidung er aufgezeichnet hat, denn der Dialog ist eine Ablehnung und keine Diagnose.

Drei Arten der Ablehnung, ein Dialog

Ein falsches Geheimnis ist nur der erste Weg zu diesem Dialog. Der Kontoname kann sich in eine Identität auflösen, die Sie nicht beabsichtigt haben, dem Konto kann die Einwählberechtigung fehlen, oder eine Serverbedingung kann die Verbindung ablehnen, nachdem das Kennwort akzeptiert wurde. Jeder dieser Fälle erzeugt denselben Clienttext, und jeder hat seine eigene Reparatur.

Deshalb scheint ein Zurücksetzen am Montag zu wirken und ändert am Dienstag nichts. Lesen Sie den Dialog als Ablehnung und nicht als Diagnose, und notieren Sie den Profilnamen und die lokale Uhrzeit des Fehlers, bevor Sie das Konto anfassen.

Die drei Kategorien scheitern zudem auf verschiedenen Ebenen. Ein falsches Geheimnis lässt den Identitätsnachweis scheitern, eine falsche Kontoform lässt die Suche scheitern, und eine Richtlinienbedingung lässt die Autorisierung scheitern, nachdem die Identität nachgewiesen wurde. Nur die erste wird durch eine Kennwortänderung repariert. Die anderen beiden brauchen jemanden mit Zugriff auf die Entscheidungsaufzeichnung des Servers, deshalb ist der nächste Schritt eine Informationsanfrage und kein weiteres Zurücksetzen.

Was der Client tatsächlich gesendet hat

Bestätigen Sie das akzeptierte Kontoformat mit dem Betreiber des Gateways, denn ein bloßer Benutzername, ein domänenqualifizierter Name und ein Benutzerprinzipalname können zu unterschiedlichen Kontokontexten führen. Nur einer davon ist möglicherweise die Identität, die die Berechtigung besitzt. Fragen Sie vor dem ersten Versuch und nicht nach dem fünften, welche Form das Gateway erwartet, und prüfen Sie, ob der Client ein gespeichertes Anmeldeinformationsobjekt statt des von Ihnen eingegebenen verwendet.

Zwei schreibgeschützte Abfragen auf dem Windows-Rechner zeigen das Profil und alle zwischengespeicherten Anmeldeinformationen, die den Dialog überstimmen könnten. Keine von beiden wählt den Server an:

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

Behandeln Sie das Kennwort als Daten und nicht als aus einem Dokument kopierten Text. Ein Wert, der durch ein Skript gelaufen ist, kann Escape-Zeichen tragen, die nie Teil des Geheimnisses waren, und ein Konfigurationsexport hat ihn vielleicht in Anführungszeichen gesetzt. Jedes Sonderzeichen zu entfernen, damit es passt, ist eine andere Änderung als den echten Wert zu finden, legen Sie also zuerst den echten Wert fest.

Holen Sie die Richtlinienentscheidung, kein Zurücksetzen

Bei einer Remotezugriff-Bereitstellung mit einem Netzwerkrichtlinienserver laufen zwei Entscheidungen nacheinander. Die Authentifizierung stellt fest, welches Konto fragt, und die Autorisierung entscheidet, ob dieses Konto überhaupt verbinden darf. Richtlinienbedingungen und -einschränkungen werden nach eigenen Maßstäben bewertet, ein korrektes Geheimnis klärt also nur die erste Hälfte der Frage. Der Richtlinienname im Serverereignis benennt, welche Entscheidung tatsächlich lief.

Senden Sie dem Administrator den Profilnamen, das versuchte Konto und den Zeitstempel. Bitten Sie um die passende Entscheidungsaufzeichnung und deren Begründung statt um ein weiteres Kennwort-Zurücksetzen und um den Richtliniennamen, den das Ereignis trägt. Microsofts Referenz zu Fehlercodes beim Remotezugriff führt 691 unter den Anmeldeinformations- und Authentifizierungsfehlern auf, und genau deshalb kann der Dialog die drei Fälle nicht trennen.

Ein Konto in eine unbedingte Erlaubnis umzuwandeln macht aus einer Autorisierungsentscheidung eine dauerhafte Ausnahme. Es entfernt außerdem die Bedingung, die nützliche Arbeit leistete, und wer die Richtlinie als Nächstes prüft, wird nicht wissen, warum sie sich geändert hat. Lassen Sie stattdessen den Eigentümer die beabsichtigte Richtlinie bestätigen, damit die Annahme bewusst bleibt.

Einmal erneut versuchen, dann vergleichen

Wiederholen Sie dasselbe Profil nach der einen Korrektur, die Sie ermittelt haben. Wird der Zugriff akzeptiert und eine interne Ressource schlägt weiterhin fehl, ist der Fehler auf eine andere Ebene gewandert und sagt nichts mehr über das Kennwort aus. Das unveränderte Profil ist es, was diesen Vergleich aussagekräftig macht.

Widerstehen Sie der Versuchung, eine Adressfamilie zu deaktivieren oder ausführliche Ablaufverfolgung zu aktivieren, bevor die Ablehnung erklärt ist. Ablaufverfolgung erzeugt Menge statt einer Entscheidung, und das erste nützliche Ergebnis bleibt die Komponente, die den Versuch abgelehnt hat, und der Grund, den sie aufgezeichnet hat. Ist das bekannt, bestätigt der erneute Versuch entweder die Reparatur oder erzeugt ein neues und engeres Symptom.