Rotiți un cont VPN local fără a-i pierde permisiunile

Înlocuirea unei parole VPN funcționale pare o modificare de două linii, până când contul reconstruit revine cu permisiuni implicite și singura sesiune de administrare a dispărut. Procedura sigură depinde de locul în care este stocată credențiala și de protocolul care o consumă, nu de comanda cea mai scurtă. Comparați cele două abordări înainte de a atinge dispozitivul. Rotația la fața locului păstrează obiectul contului; ștergerea și recrearea îl înlocuiesc, iar tot ce indica spre el pleacă împreună cu el.

Aflați ce depozit autentifică de fapt sesiunea

Începeți de la profilul tunelului sau al conexiunii, nu de la baza de date cu utilizatori. Profilul numește o metodă de autentificare și adesea un grup de servere, iar dacă acel grup indică spre RADIUS sau TACACS+, numele de utilizator local de pe echipament este doar decor. Citiți lista de autentificare a profilului și grupul AAA la care face referire înainte de a planifica ceva. Numai când profilul spune local contează contul de pe echipament. Greșiți aici și veți roti o credențială pe care nimeni nu o folosește, în timp ce intrarea reală din director rămâne exact cum era.

Același dispozitiv găzduiește de obicei două populații: administratori care se conectează la el și utilizatori VPN care încheie un tunel. Pot împărți un depozit și nu trebuie presupus că o fac.

Actualizare la fața locului versus ștergere și recreare

Rotația la fața locului modifică un singur atribut al unui obiect existent. Nivelul de privilegiu, apartenența la grupuri, atributele de autorizare și orice politică ce face referire la cont supraviețuiesc, pentru că nu s-a eliminat nimic. Ștergerea și recrearea reconstruiesc obiectul dintr-o linie de comandă, așa că fiecare câmp pe care nu l-ați repetat revine la valoarea implicită. Pe un dispozitiv unde atributele per utilizator poartă alocări de tunel divizat sau de pool de adrese, acea diferență este întregul risc.

Reconstrucția are o singură utilizare legitimă: atunci când formatul stocat trebuie schimbat și platforma nu oferă nicio conversie. Chiar și atunci, înregistrați mai întâi intrarea existentă, pentru că configurația în execuție este singurul inventar exact al ceea ce purta contul. O copie a acelei configurații luată înainte de modificare valorează mai mult decât un plan de revenire scris din memorie.

De ce hash-ul pe care îl aveți poate să nu fie secretul de care are nevoie

Formatele de stocare diferă într-un mod care decide răspunsul. Un hash unidirecțional poate verifica o parolă atunci când serverul o primește în clar în interiorul tunelului, dar o metodă challenge-response are nevoie de secretul partajat însuși pentru a calcula rezumatul. Prin urmare, convertirea fiecărui cont la cel mai puternic format unidirecțional poate rupe CHAP sau MS-CHAP exact pentru utilizatorii care depind de el.

Decideți după protocol, nu după slogan. Acolo unde metoda cere un secret recuperabil, această cerință este o constrângere de proiectare și nu o scăpare de curățat.

Sesiuni care supraviețuiesc credențialei

Schimbarea unei credențiale nu închide sesiunile care s-au autentificat deja. Un partener cu un tunel stabilit continuă să funcționeze până la reînnoirea cheii, reautentificare sau deconectare explicită.

Planificați acea parte separat și planificați-o înainte de modificare. Dacă credențiala a scăpat, lăsarea sesiunilor active anulează rotația. Dacă doar a expirat, forțarea tuturor partenerilor offline este o întrerupere de care nu aveați nevoie. Țineți deschisă o a doua cale de administrare în timp ce lucrați, de preferință una care nu depinde de contul editat, pentru că modul de eșec de aici vă ia accesul exact când aveți nevoie de el. Apoi verificați o autentificare nouă și resursele la care poate ajunge.

Dovediți că permisiunile au supraviețuit

Autentificați-vă ca utilizatorul rotit și verificați ce acordă sesiunea, nu doar că s-a deschis. Ajungeți la o resursă care cere autorizarea pe care contul ar trebui să o poarte și încercați una la care nu ar trebui să ajungă. O autentificare reușită cu acces restrâns sau extins este o modificare eșuată.

Comparați atributele de autorizare din configurația în execuție cu copia luată la început. Uitați-vă la apartenența la grupuri, pool-ul de adrese, setările DNS și de tunel divizat, și la orice obiect de politică ce numea contul. Apoi actualizați evidența locului unde trăiește acea credențială, pentru că următoarea rotație începe de la acea notă. O rotație pe care nimeni nu o poate repeta din documentație a fost depășită o singură dată.