Én enhet kan fortsatt ikke koble til etter tilbakestilling av VPN-passordet

Du tilbakestilte passordet, testet det i portalen, og én bærbar datamaskin kan fortsatt ikke koble til. Instinktet er å tilbakestille det igjen, og det er nettopp slik en konto blir låst og en foreldet hemmelighet blir en hendelse. En VPN-klient ber sjelden om et passord hver gang; den ber én gang og lagrer svaret et sted du ikke valgte. Å finne det stedet er hele jobben, og det er raskere enn nok en tilbakestilling.

Bekreft hva hver klient faktisk sender

Kontroller kontoen, domenet og gatewayen på klienten som feiler før du antar at passordet er problemet. En innlogging i nettportalen kan bruke et annet identitetssystem enn selve VPN-en, så en vellykket portallogin sier ingenting om protokollens autentisering. Noen utrullinger godtar en e-postadresse i portalen og et annet brukernavn i tunnelen. Bekreft hvilken identitet klienten er konfigurert til å presentere før du tilbakestiller noe.

Les feilteksten og klassifiser den. En sertifikatfeil, en utløpt utfordring eller en chiffer som ikke støttes er ikke et foreldet passord, og å behandle det som ett gir en tilbakestillingsløkke uten effekt. Hvis tjenesten har en utelåsingspolicy, stopp etter to eller tre mislykkede forsøk og bekreft kontotilstanden før du fortsetter.

List opp lagerne i stedet for å gjette

Fire lagre holder en VPN-hemmelighet, og tabellen nedenfor viser for hvert av dem hvor verdien overlever og hva det egentlig betyr å slette den. En innebygd OS-profil holder hemmeligheten i plattformens legitimasjonslager, og derfor kan oppføringen overleve applikasjonen som skrev den. En klientkonfigurasjonsfil holder verdien der klienten leser den, enten innebygd eller i en referert autentiseringsfil, så å redigere en annen fil endrer ingenting. En nettleserportal-cookie og en legitimasjon levert av policy lever et sted enheten egentlig ikke eier, og det avgjør hvem som har lov til å endre dem.

Kontroller dem i en fast rekkefølge: først OS-ets legitimasjonslager, fordi det er det klienten konsulterer som standard, deretter klientens eget hvelv eller konfigurasjonsfil, så nettleserøkten og til slutt policyen som kan overskrive alle tre. Rekkefølgen er viktig fordi et senere lager stille kan gjenopprette et tidligere, og du vil ha rettet feil lag mens feilen vedvarer. Skriv ned hvilket lager du endret, fordi den notaten er det som gjør den neste tilbakestillingen til en to-minutters jobb i stedet for en hel ettermiddag.

Se i lageret klienten faktisk bruker

Les før du sletter, slik at du vet hvilken oppføring som tilhørte VPN-en. Kommandoene nedenfor lister opp og undersøker i stedet for å fjerne, noe som holder 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 password

På Linux viser -s hemmeligheter som NetworkManager ellers skjuler. På macOS skriver Keychain-kommandoen ut det lagrede elementet, så behandl terminalens rullehistorikk som sensitiv. Hvis klienten som feiler er en tredjepartsapp med eget hvelv, vil OS-lageret se riktig ut mens appen beholder sin egen kopi, og det hvelvet er der endringen hører hjemme.

Håndter enhetene som er frakoblet

Bærbare datamaskiner som våkner og kobler til på nytt av seg selv vil fortsette å presentere den gamle hemmeligheten så lenge kopien deres finnes. Planlegg oppdateringen slik at disse enhetene rettes før de prøver igjen i en bølge, og vurder å deaktivere automatisk tilkobling på den berørte profilen til hver av dem har vært gjennom den støttede flyten.

For en administrert flåte endrer du verdien der policyen er definert. Å redigere en lokal kopi på en enhet hvis legitimasjon leveres sentralt er i beste fall midlertidig; neste policyoppdatering gjenoppretter den gamle verdien, og feilen kommer tilbake uten forklaring.

Bekreft med ett kontrollert forsøk

Oppdater den tiltenkte oppføringen, koble til på nytt én gang og bekreft at tunnelen når noe konkret. Ett kontrollert forsøk gir en brukbar feil hvis det feiler, mens tjue gir en låst konto og et mysterium. Hvis en klient fortsatt feiler etter at lageret er rettet, fang én enkelt feil uten hemmeligheter og stopp. Ta vare på feilen sammen med enhetsnavnet slik at neste skift begynner der du sluttet.

En passordendring berører ikke sertifikater, sesjonstokener eller MFA-registrering, og det er separate identiteter med sin egen livssyklus. Et fornyet sertifikat rettes ikke ved å rotere et passord, og et token utstedt før tilbakestillingen kan fortsatt være gyldig. Avslutt med å skrive ned hvilket lager som holdt den foreldede verdien, fordi neste tilbakestilling vil treffe den samme listen.