Migrarea unui backend de autentificare VPN fără reutilizarea hashurilor vechi

Numele de utilizator apar în noul director, migrarea este declarată încheiată, iar autentificările continuă să eșueze. Gateway-ul are în continuare nevoie de o cale de autentificare acceptată și de un rezultat corect de autorizare, și niciuna nu decurge dintr-un director care conține acum conturile. Mutarea unui backend este o comutare cu ciclu de viață, nu o sarcină de copiere. Simptomul de mai jos este cel care dezvăluie de obicei diferența.

Simptomul: conturile există, sesiunile nu

Noul director conține fiecare nume de utilizator, o legare de test reușește, iar clientul VPN returnează în continuare o eroare de autentificare. Această combinație înseamnă că identitatea există, dar calea de verificare folosită de gateway nu ajunge la ea, sau ajunge cu o metodă pe care nu o poate satisface. Ambele sunt configurare și sunt probleme diferite.

Prima este instalația: gateway-ul indică un backend care nu răspunde, folosește un secret partajat pe care cealaltă parte nu îl așteaptă sau cere un atribut pe care noul serviciu nu îl returnează. A doua este criptografică: metoda cere secretul original, iar noul depozit păstrează doar un hash al acestuia. Textul erorii seamănă în ambele cazuri, de aceea cele două sunt tratate ca o singură problemă.

Separarea celor două înainte de a atinge conturile economisește o săptămână. Una este o chestiune de rutare și încredere, cealaltă o decizie privind resetarea credențialelor, iar amestecarea lor produce schimbări pe care nimeni nu le poate atribui.

Cartografiază lanțul înainte de a muta pe cineva

Notează șase lucruri pentru fiecare profil de client: metoda de autentificare externă, orice metodă internă, identitatea de server pe care o așteaptă clientul, interfața dintre gateway și backend, atributul pe care gateway-ul îl mapează la apartenența la grup și politica de resurse rezultată. Citirea lor în ordine arată care verigă nu are proprietar. Fiecare element are un responsabil, iar comutarea eșuează la cel pe care nimeni nu l-a verificat.

O autentificare obișnuită în director nu parcurge aproape nimic din acel lanț. Dovedește că contul există și că parola funcționează, adică exact partea care nu a fost niciodată pusă la îndoială.

Hashurile nu călătoresc între metode

Compatibilitatea credențialelor trebuie verificată o dată, înainte de a muta orice cohortă. FreeRADIUS documentează clar separarea: o verificare CHAP pe care serverul o efectuează singur are nevoie de parola reală, iar MS-CHAP acceptă acea parolă sau material NT adecvat. Un hash creat în alt scop nu se potrivește niciunuia dintre cazuri, oricât de puternic ar fi.

Distincția privește cine calculează dovada. O metodă care verifică prin legarea la director lasă directorul să verifice ce poate verifica. O metodă care verifică prin recalcularea unui răspuns la provocare are nevoie de secretul însuși, fiindcă serverul trebuie să execute același calcul.

Unde materialul lipsește, opțiunile oneste sunt o resetare acceptată, o reînrolare, un serviciu extern de verificare sau o schimbare de metodă. O exportare temporară de parole recuperabile nu se află pe acea listă. Creează un depozit de credențiale în text clar în cea mai haotică săptămână a proiectului și de obicei supraviețuiește migrării.

Cohortă pilot, apoi schimbări de ciclu de viață

Mută o cohortă mică de identități aprobate cu clientul real și testează patru lucruri: o autentificare nouă, o credențială intenționat greșită, resursele pe care sesiunea le poate atinge și resursele pe care nu trebuie să le atingă. Verifică și identitatea de server acceptată de client, fiindcă o nepotrivire a numelui certificatului este invizibilă până când cineva citește jurnalul clientului.

Apoi exersează schimbările de care depinde efectiv implementarea. Schimbă o parolă, reînnoiește sau reînrolează un certificat și retrage accesul unui cont pilot. După fiecare, confirmă ce verificator a tratat încercarea, fiindcă o sesiune creată înainte de comutare poate continua să funcționeze și nu dovedește nimic despre următoarea autentificare.

Separă livrarea profilului de schimbarea identității. Fiecare cohortă are nevoie de profilul prevăzut, de starea credențialei sau a înrolării, de serviciul de autentificare pe care trebuie să îl folosească și de un contact de suport, iar niciuna dintre aceste înregistrări nu trebuie să conțină un secret.

Dacă vechea și noua cale coexistă, delimitează-le cu o dată de încheiere. O revenire automată poate admite un cont prin intermediul unei credențiale vechi după ce noul proprietar a retras accesul, iar aceasta este o regresie de securitate deghizată în disponibilitate.

Revenirea nu poate restabili o credențială

Inversarea comutării lasă directorul exact în starea în care este acum. O parolă resetată rămâne resetată, un certificat revocat rămâne revocat, iar un format de credențială schimbat rămâne schimbat. Sunt evenimente în director, iar gateway-ul nu a fost niciodată sursa lor. Recuperarea trebuie definită pe eveniment, iar nimic din toate acestea nu poate depinde de reconstruirea unui secret dintr-un hash incompatibil.

Păstrează o cale administrativă care nu folosește conexiunea migrată. Când noua autentificare eșuează, oprește cohorta și folosește calea ei documentată de recuperare, în loc să slăbești autentificarea pentru toți ca să respecți un termen.

După ce cohortele sunt acoperite, retrage credențialele, profilele și relațiile de încredere vechi ale backend-ului prin proprietarii lor. Confirmă că vechea cale nu mai admite utilizatori și păstrează maparea identitate-politică fără secrete de care suportul mai are nevoie. O migrare este încheiată când noul ciclu de viață funcționează și nimeni nu mai intră pe vechea cale, nu când lista de conturi pare completă.