En enhet misslyckas fortfarande efter återställning av VPN-lösenordet
Det nya lösenordet fungerar överallt utom hos en klient. Hitta lagret som fortfarande håller det gamla värdet, begränsa försöken och verifiera med ett försök.
Du återställde lösenordet, testade det i portalen, och en laptop kan fortfarande inte ansluta. Instinkten är att återställa det igen, och det är så ett konto blir låst och en gammal hemlighet blir en incident. En VPN-klient frågar sällan efter lösenordet varje gång; den frågar en gång och sparar svaret någonstans du inte valde. Att hitta den platsen är hela jobbet, och det går snabbare än ännu en återställning.
Bekräfta vad varje klient faktiskt skickar
Kontrollera kontot, domänen och gatewayen på den misslyckade klienten innan du antar att lösenordet är problemet. En inloggning i webbportalen kan använda ett annat identitetssystem än själva VPN:en, så en lyckad inloggning i portalen säger ingenting om protokollets autentisering. Vissa installationer accepterar en e-postadress i portalen och ett annat användarnamn i tunneln. Bekräfta vilken identitet klienten är konfigurerad att presentera innan du återställer något.
Läs feltexten och klassificera den. Ett certifikatfel, en utgången utmaning eller ett chiffer som inte stöds är inte ett gammalt lösenord, och att behandla det som ett ger en återställningsloop utan effekt. Om tjänsten har en utlåsningspolicy, stoppa efter två eller tre misslyckade försök och bekräfta kontots status innan du fortsätter.
Lista lagren i stället för att gissa
Fyra lager håller en VPN-hemlighet, och tabellen nedan kopplar varje lager till var värdet överlever och vad rensningen faktiskt innebär. En inbyggd OS-profil håller hemligheten i plattformens autentiseringslager, vilket är varför posten kan överleva programmet som skrev den. En klientkonfigurationsfil håller värdet där den klienten läser det, antingen inbäddat eller i en refererad auth-fil, så att redigera en annan fil ändrar ingenting. En portalkaka i webbläsaren och en autentiseringsuppgift som levereras av policy bor någonstans som enheten egentligen inte äger, och det avgör vem som får ändra dem.
| Store | Where it lives | How to clear it |
|---|---|---|
| Native OS profile | Windows Credentials, NetworkManager secrets | forget or edit the connection |
| Client configuration file | a referenced auth file or inline value | edit the file the client actually reads |
| Browser session | cookie for the portal SSO | sign out of the portal, not just close the tab |
| Managed policy | delivered by the management service | change it in the manager, not on the device |
Kontrollera dem i en fast ordning: först OS:ets autentiseringslager, eftersom det är det klienten använder som standard, sedan klientens eget valv eller konfigurationsfil, sedan webbläsarsessionen och till sist policyn som kan skriva över alla tre. Ordningen spelar roll eftersom ett senare lager tyst kan återställa ett tidigare, och du kommer att ha fixat fel lager medan felet kvarstår. Skriv ned vilket lager du ändrade, för den anteckningen gör nästa återställning till ett tvåminutersjobb i stället för en hel eftermiddag.
Titta i lagret som klienten faktiskt använder
Läs innan du raderar, så att du vet vilken post som tillhörde VPN:en. Kommandona nedan listar och inspekterar i stället för att ta bort, vilket håller diagnosen reversibel.
# 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 passwordPå Linux -s visar hemligheter som NetworkManager annars döljer. På macOS skriver Keychain-kommandot ut det lagrade objektet, så behandla terminalens rullningshistorik som känslig. Om den misslyckade klienten är ett tredjepartsprogram med eget valv ser OS-lagret korrekt ut medan programmet behåller sin egen kopia, och det är i det valvet ändringen hör hemma.
Hantera enheterna som är offline
Laptops som vaknar och återansluter utan tillsyn kommer att fortsätta presentera den gamla hemligheten så länge deras kopia finns. Planera uppdateringen så att dessa enheter rättas innan de försöker igen i en skur, och överväg att stänga av automatisk anslutning på den berörda profilen tills var och en har gått igenom det stödda flödet.
För en hanterad flotta, ändra värdet där policyn definieras. Att redigera en lokal kopia på en enhet vars autentiseringsuppgift tillhandahålls centralt är i bästa fall tillfälligt; nästa policyuppdatering återställer det gamla värdet och felet återkommer utan förklaring.
Verifiera med ett kontrollerat försök
Uppdatera den avsedda posten, återanslut en gång och bekräfta att tunneln når något specifikt. Ett kontrollerat försök ger ett användbart fel om det misslyckas, medan tjugo ger ett låst konto och ett mysterium. Om en klient fortfarande misslyckas efter att lagret rättats, fånga ett enda icke-hemligt fel och stoppa. Behåll felet tillsammans med enhetsnamnet så att nästa skift börjar där du slutade.
En lösenordsändring rör inte certifikat, sessionstoken eller MFA-registrering, och dessa är separata identiteter med sin egen livscykel. Ett förnyat certifikat fixas inte genom att rotera ett lösenord, och en token som utfärdats före återställningen kan fortfarande vara giltig. Avsluta med att skriva ned vilket lager som höll det gamla värdet, för nästa återställning träffar samma lista.