Éin eining feilar framleis etter tilbakestilling av VPN-passordet

Du tilbakestilte passordet, testa det i portalen, og éin laptop får framleis ikkje tilkopling. Instinktet er å tilbakestille det igjen, og det er slik ein konto blir låst og ein forelda løyndom blir ei hending. Ein VPN-klient ber sjeldan om eit passord kvar gong; han ber éin gong og lagrar svaret ein stad du ikkje valde. Å finne den staden er heile jobben, og det er raskare enn nok ei tilbakestilling.

Stadfest kva kvar klient faktisk sender

Sjekk kontoen, domenet og gatewayen på den feilande klienten før du går ut frå at passordet er problemet. Ei portalinngåing kan bruke eit anna identitetssystem enn VPN-en sjølv, så ei vellukka innlogging i portalen seier ingenting om autentiseringa til protokollen. Nokre installasjonar godtek ein e-postadresse i portalen og eit anna brukarnamn i tunnelen. Stadfest kva identitet klienten er konfigurert til å presentere før du tilbakestiller noko.

Les feilteksten og klassifiser han. Ein sertifikatfeil, ei utløpt utfordring eller ein chiffersuite som ikkje er støtta er ikkje eit forelda passord, og å handsame det som eitt gir ei tilbakestillingsløkke utan effekt. Viss tenesta har ein låsepolicy, stopp etter to eller tre mislukka forsøk og stadfest kontotilstanden før du held fram.

Kartlegg lagera i staden for å gjette

Fire lager held ein VPN-løyndom, og tabellen nedanfor knyter kvart av dei til kvar verdien overlever og kva det å slette han faktisk tyder. Ein innebygd OS-profil held løyndomen i legitimasjonslageret til plattformen, og derfor kan oppføringa leve lengre enn programmet som skreiv henne. Ei klientkonfigurasjonsfil held verdien der den klienten les han, anten innebygd eller i ei referert auth-fil, så å redigere ei anna fil endrar ingenting. Ei portal-kake i nettlesaren og ein legitimasjon levert av policy lever ein stad eininga eigentleg ikkje eig, og det avgjer kven som har lov til å endre dei.

Sjekk dei i ein fast rekkjefølgje: OS-legitimasjonslageret først, fordi det er det klienten brukar som standard, så eigen kvelv eller konfigurasjonsfil hos klienten, så nettlesarøkta, og til slutt policyen som kan overskrive alle tre. Rekkjefølgja har noko å seie fordi eit seinare lager stille kan gjenopprette eit tidlegare, og du vil ha retta feil lag medan feilen held fram. Skriv ned kva lager du endra, for den notata er det som gjer den neste tilbakestillinga til ein tomeminnuttsjobb i staden for ein ettermiddag.

Sjå i lageret klienten faktisk brukar

Les før du slettar, så du veit kva oppføring som høyrde til VPN-en. Kommandoane nedanfor listar opp og inspiserer i staden for å fjerne, noko som held diagnosen reverserbar.

# 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 løyndomar som NetworkManager elles skjuler. På macOS skriv Keychain-kommandoen ut det lagra elementet, så handsame rullehistorikken i terminalen som sensitiv. Viss den feilande klienten er ein tredjepartsapp med eigen kvelv, vil OS-lageret sjå riktig ut medan appen held sin eigen kopi, og det er den kvelven endringa høyrer heime i.

Handter einingane som er fråkopla

Laptoper som vaknar og koplar til på nytt utan tilsyn vil halde fram med å presentere den gamle løyndomen så lenge kopien deira finst. Planlegg oppdateringa slik at desse einingane er retta før dei prøver igjen i ein bylgje, og vurder å slå av automatisk tilkopling på den råka profilen til kvar av dei har vore gjennom den støtta flyten.

For ein styrt flåte endrar du verdien der policyen er definert. Å redigere ein lokal kopi på ei eining der legitimasjonen blir provisionert sentralt er i beste fall mellombels; neste policysyklus gjenopprettar den gamle verdien og feilen kjem tilbake utan forklaring.

Stadfest med eitt kontrollert forsøk

Oppdater den tiltenkte oppføringa, kople til éin gong på nytt, og stadfest at tunnelen når noko konkret. Eitt kontrollert forsøk gir ein brukbar feil viss det mislukkast, medan tjue gir ein låst konto og eit mysterium. Viss ein klient framleis feilar etter at lageret er retta, fang éin ikkje-løyndomsfeil og stopp. Ta vare på feilen saman med einingnamnet, så neste skift byrjar der du slutta.

Ei passordendring rører ikkje sertifikat, sesjonstoken eller MFA-registrering, og det er separate identitetar med sin eigen livssyklus. Eit fornya sertifikat blir ikkje retta ved å rotere eit passord, og eit token utstedt før tilbakestillinga kan framleis vere gyldig. Avslutt med å skrive ned kva lager som heldt den forelda verdien, for den neste tilbakestillinga vil treffe den same lista.