Migrácia VPN autentizačného backendu bez opätovného použitia starých hashov
Presun VPN identít je cutover, nie kópia: zmapujte autentizačný reťaz, preveďte pilotnú skupinu, otestujte zmeny prihlasovacích údajov a naplánujte obnovu, ktorú reset nevráti.
Používateľské mená sa objavia v novom adresári, migrácia je vyhlásená za dokončenú a prihlásenia napriek tomu zlyhávajú. Brána stále potrebuje podporovanú autentizačnú cestu a správny výsledok autorizácie a ani jedno nevyplýva z adresára, ktorý teraz účty obsahuje. Presun backendu je cutover so životným cyklom, nie kopírovanie. Symptóm nižšie je ten, ktorý rozdiel zvyčajne odhalí.
Symptóm: účty existujú, relácie nie
Nový adresár obsahuje každé používateľské meno, testovací bind uspeje a VPN klient stále vracia chybu autentizácie. Taká kombinácia znamená, že identita existuje, ale overovacia cesta, ktorú brána používa, sa k nej nedostane, alebo sa k nej dostane metódou, ktorú nemôže splniť. Oboje je konfigurácia a ide o rôzne problémy.
Prvé je kabeláž: brána ukazuje na backend, ktorý neodpovedá, používa zdieľané tajomstvo, ktoré druhá strana neočakáva, alebo žiada atribút, ktorý nová služba nevracia. Druhé je kryptografické: metóda vyžaduje pôvodné tajomstvo a nové úložisko obsahuje len jeho hash. Text chyby vyzerá v oboch prípadoch podobne, a preto sa oba prípady liečia ako jeden problém.
Oddeliť oba prípady skôr, než sa siahne na účty, ušetrí týždeň. Jeden je otázka smerovania a dôvery, druhý rozhodnutie o resete prihlasovacích údajov, a ich zmiešanie vytvára zmeny, ktoré nikto nedokáže pripísať.
Zmapujte reťaz, než niekoho presuniete
Pre každý klientsky profil zapíšte šesť vecí: vonkajšiu autentizačnú metódu, prípadnú vnútornú metódu, identitu servera, ktorú klient očakáva, rozhranie medzi bránou a backendom, atribút, ktorý brána mapuje na členstvo v skupine, a výslednú zásadu pre prostriedky. Čítanie v tomto poradí ukáže, ktorý článok nikto nevlastní. Každá položka má vlastníka a cutover zlyhá na tej, ktorú nikto neprekontroloval.
| Link | Question it answers |
|---|---|
| Client profile | Which method and server name does the client use? |
| Inner method | Is there a second authentication step? |
| Server identity | Which certificate or name must the client accept? |
| Gateway to backend | Which protocol, port and shared secret? |
| Attribute mapping | Which returned value becomes group membership? |
| Resource policy | What the resulting session may reach |
Bežné prihlásenie do adresára neprejde takmer ničím z tohto reťazca. Preukáže, že účet existuje a heslo funguje, čo je práve tá časť, o ktorej nikdy nebolo pochýb.
Hashy medzi metódami necestujú
Kompatibilitu prihlasovacích údajov treba skontrolovať raz, než sa niektorá skupina presunie. FreeRADIUS opisuje rozdelenie jasne: kontrola CHAP, ktorú vykonáva sám server, potrebuje skutočné heslo a MS-CHAP prijíma toto heslo alebo vhodný NT materiál. Hash vytvorený na iný účel nesedí ani na jeden prípad, nech je akokoľvek silný.
Rozdiel je v tom, kto počíta dôkaz. Metóda, ktorá overuje naviazaním na adresár, nechá adresár skontrolovať, čo skontrolovať vie. Metóda, ktorá overuje prepočtom odpovede na výzvu, potrebuje samotné tajomstvo, pretože server musí vykonať rovnaký výpočet.
Kde materiál chýba, sú poctivé možnosti podporovaný reset, nová registrácia, externá overovacia služba alebo zmena metódy. Dočasný export obnoviteľných hesiel na tomto zozname nie je. Vytvára úložisko prihlasovacích údajov v otvorenom texte počas najchaotickejšieho týždňa projektu a zvyčajne migráciu prežije.
Pilotná skupina, potom zmeny životného cyklu
Presuňte malú skupinu schválených identít so skutočným klientom a otestujte štyri veci: čerstvé prihlásenie, zámerne nesprávny prihlasovací údaj, prostriedky, ktoré relácia smie dosiahnuť, a prostriedky, ktoré nesmie. Skontrolujte aj identitu servera, ktorú klient prijal, pretože nezhoda názvu certifikátu je neviditeľná, kým niekto neprečíta klientsky log.
Potom prejdite zmeny, na ktorých nasadenie skutočne závisí. Zmeňte heslo, obnovte alebo znova zaregistrujte certifikát a jednému pilotnému účtu odoberte prístup. Po každej z nich potvrďte, ktorý overovateľ pokus obslúžil, pretože relácia vytvorená pred cutoverom môže ďalej fungovať a nič nepreukazuje o nasledujúcom prihlásení.
Oddeľte doručenie profilu od prepnutia identity. Každá skupina potrebuje zamýšľaný profil, svoj stav prihlasovacích údajov alebo registrácie, autentizačnú službu, ktorú má používať, a kontakt na podporu, a žiadny z týchto záznamov nesmie obsahovať tajomstvo.
Ak stará a nová cesta existujú vedľa seba, ohraničte ich koncovým dátumom. Automatický fallback môže pustiť účet cez starý prihlasovací údaj po tom, čo nový vlastník odobral prístup, a to je bezpečnostná regresia vydávaná za dostupnosť.
Rollback nedokáže obnoviť prihlasovací údaj
Vrátenie cutoveru ponechá adresár presne v tom stave, v akom je teraz. Resetované heslo zostane resetované, odvolaný certifikát zostane odvolaný a zmenený formát prihlasovacích údajov zostane zmenený. To sú udalosti v adresári a brána nikdy nebola ich zdrojom. Obnova musí byť definovaná pre každú udalosť a nič z toho nesmie závisieť od rekonštrukcie tajomstva z nekompatibilného hashu.
Udržujte administratívnu cestu, ktorá nepoužíva migrované spojenie. Keď nová autentizácia zlyhá, pozastavte skupinu a použite jej zdokumentovanú cestu obnovy, namiesto toho, aby ste oslabili autentizáciu pre všetkých, len aby ste stihli termín.
Keď sú skupiny pokryté, vyraďte staré backendové prihlasovacie údaje, profily a vzťahy dôvery prostredníctvom ich vlastníkov. Potvrďte, že stará cesta už používateľov nepúšťa, a ponechajte mapovanie identity na zásadu bez tajomstva, ktoré podpora ešte potrebuje. Migrácia je hotová, keď nový životný cyklus funguje a nikto sa už nedostane starou cestou, nie keď sa zoznam účtov zdá byť úplný.