Ein Gerät schlägt nach dem Zurücksetzen des VPN-Passworts weiterhin fehl

Sie haben das Passwort zurückgesetzt, es im Portal getestet, und ein Laptop kann sich immer noch nicht verbinden. Der Instinkt ist, es erneut zurückzusetzen, und genau so wird ein Konto gesperrt und ein veraltetes Geheimnis wird zum Vorfall. Ein VPN-Client fragt selten jedes Mal nach einem Passwort; er fragt einmal und speichert die Antwort an einem Ort, den Sie nicht gewählt haben. Diesen Ort zu finden ist die ganze Aufgabe, und es geht schneller als ein weiteres Zurücksetzen.

Bestätigen Sie, was jeder Client tatsächlich sendet

Prüfen Sie Konto, Domäne und Gateway auf dem fehlschlagenden Client, bevor Sie das Passwort als Problem annehmen. Eine Webportal-Anmeldung kann ein anderes Identitätssystem als das VPN selbst verwenden, sodass eine erfolgreiche Portal-Anmeldung nichts über die Authentifizierung des Protokolls aussagt. Manche Bereitstellungen akzeptieren im Portal eine E-Mail-Adresse und im Tunnel einen anderen Benutzernamen. Bestätigen Sie, welche Identität der Client präsentieren soll, bevor Sie irgendetwas zurücksetzen.

Lesen Sie den Fehlertext und klassifizieren Sie ihn. Ein Zertifikatsfehler, eine abgelaufene Challenge oder eine nicht unterstützte Chiffre ist kein veraltetes Passwort, und die Behandlung als solches erzeugt eine Zurücksetzungs-Schleife ohne Wirkung. Wenn der Dienst eine Sperrrichtlinie hat, hören Sie nach zwei oder drei fehlgeschlagenen Versuchen auf und bestätigen Sie den Kontostatus, bevor Sie fortfahren.

Zählen Sie die Speicher auf, statt zu raten

Vier Speicher halten ein VPN-Geheimnis, und die Tabelle unten zeigt für jeden, wo der Wert überlebt und was das Löschen tatsächlich bedeutet. Ein natives OS-Profil hält das Geheimnis im Anmeldeinformationsspeicher der Plattform, weshalb der Eintrag die Anwendung überleben kann, die ihn geschrieben hat. Eine Client-Konfigurationsdatei hält den Wert dort, wo dieser Client ihn liest, entweder inline oder in einer referenzierten Auth-Datei, sodass das Bearbeiten einer anderen Datei nichts ändert. Ein Browserportal-Cookie und ein richtlinienbereitgestelltes Anmeldeinformationsobjekt leben an einem Ort, den das Gerät nicht wirklich besitzt, was entscheidet, wer sie ändern darf.

Prüfen Sie sie in einer festen Reihenfolge: zuerst den Anmeldeinformationsspeicher des Betriebssystems, weil der Client standardmäßig ihn konsultiert, dann den eigenen Tresor oder die Konfigurationsdatei des Clients, dann die Browsersitzung und schließlich die Richtlinie, die alle drei überschreiben kann. Die Reihenfolge ist wichtig, weil ein späterer Speicher einen früheren stillschweigend wiederherstellen kann, und Sie werden die falsche Schicht repariert haben, während der Fehler bestehen bleibt. Notieren Sie, welchen Speicher Sie geändert haben, denn diese Notiz macht das nächste Zurücksetzen zu einer Zwei-Minuten-Aufgabe statt zu einem ganzen Nachmittag.

Sehen Sie in dem Speicher nach, den der Client tatsächlich verwendet

Lesen Sie, bevor Sie löschen, damit Sie wissen, welcher Eintrag zum VPN gehörte. Die folgenden Befehle listen auf und prüfen, statt zu entfernen, was die Diagnose umkehrbar hält.

# Windows credential store
cmdkey /list | findstr /i vpn

# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid

# macOS Keychain
security find-generic-password -s "Company VPN" -g

# Linux NetworkManager
nmcli -s connection show "Work" | grep -i password

Unter Linux zeigt -s Geheimnisse, die NetworkManager sonst verbirgt. Unter macOS gibt der Keychain-Befehl das gespeicherte Element aus, behandeln Sie den Terminal-Scrollback also als sensibel. Wenn der fehlschlagende Client eine Drittanbieter-App mit eigenem Tresor ist, wird der OS-Speicher korrekt aussehen, während die App ihre eigene Kopie behält, und dieser Tresor ist der Ort für die Änderung.

Behandeln Sie die Geräte, die offline sind

Laptops, die von selbst aufwachen und sich wieder verbinden werden das alte Geheimnis weiter präsentieren, solange ihre Kopie existiert. Planen Sie die Aktualisierung so, dass diese Geräte korrigiert werden, bevor sie in einem Schub erneut versuchen, und erwägen Sie, die automatische Verbindung im betroffenen Profil zu deaktivieren, bis jedes den unterstützten Ablauf durchlaufen hat.

Für eine verwaltete Flotte ändern Sie den Wert dort, wo die Richtlinie definiert ist. Das Bearbeiten einer lokalen Kopie auf einem Gerät, dessen Anmeldeinformationen zentral bereitgestellt werden, ist bestenfalls vorübergehend; die nächste Richtlinienaktualisierung stellt den alten Wert wieder her, und der Fehler kehrt ohne Erklärung zurück.

Prüfen Sie mit einem kontrollierten Versuch

Aktualisieren Sie den vorgesehenen Eintrag, verbinden Sie sich einmal erneut und bestätigen Sie, dass der Tunnel etwas Bestimmtes erreicht. Ein kontrollierter Versuch liefert bei einem Fehlschlag einen brauchbaren Fehler, während zwanzig ein gesperrtes Konto und ein Rätsel liefern. Wenn ein Client auch nach der Korrektur des Speichers fehlschlägt, erfassen Sie einen einzigen Fehler ohne Geheimnisse und hören Sie auf. Bewahren Sie diesen Fehler zusammen mit dem Gerätenamen auf, damit die nächste Schicht dort beginnt, wo Sie aufgehört haben.

Eine Passwortänderung berührt keine Zertifikate, Sitzungstoken oder MFA-Registrierung, und das sind getrennte Identitäten mit eigenem Lebenszyklus. Ein erneuertes Zertifikat wird nicht durch Passwortrotation behoben, und ein vor dem Zurücksetzen ausgestelltes Token kann noch gültig sein. Schließen Sie ab, indem Sie notieren, welcher Speicher den veralteten Wert hielt, denn das nächste Zurücksetzen trifft dieselbe Liste.