Migrace VPN autentizačního backendu bez opětovného použití starých hashů
Přesun VPN identit je cutover, ne kopie: zmapujte autentizační řetěz, převeďte pilotní skupinu, otestujte změny přihlašovacích údajů a naplánujte obnovu, kterou reset nevrátí.
Uživatelská jména se objeví v novém adresáři, migrace je prohlášena za dokončenou a přihlášení přesto selhávají. Brána stále potřebuje podporovanou autentizační cestu a správný výsledek autorizace a ani jedno nevyplývá z adresáře, který nyní účty obsahuje. Přesun backendu je cutover s životním cyklem, ne kopírování. Symptom níže je ten, který rozdíl obvykle odhalí.
Symptom: účty existují, relace ne
Nový adresář obsahuje každé uživatelské jméno, testovací bind uspěje a VPN klient stále vrací chybu autentizace. Taková kombinace znamená, že identita existuje, ale ověřovací cesta, kterou brána používá, se k ní nedostane, nebo se k ní dostane metodou, kterou nemůže splnit. Obojí je konfigurace a jde o různé problémy.
První je kabeláž: brána ukazuje na backend, který neodpovídá, používá sdílené tajemství, které druhá strana neočekává, nebo žádá atribut, který nová služba nevrací. Druhý je kryptografický: metoda vyžaduje původní tajemství a nové úložiště obsahuje pouze jeho hash. Text chyby vypadá v obou případech podobně, a proto se oba případy léčí jako jeden problém.
Oddělit oba případy dřív, než se sáhne na účty, ušetří týden. Jeden je otázka směrování a důvěry, druhý rozhodnutí o resetu přihlašovacích údajů, a jejich smíchání vytváří změny, které nikdo nedokáže připsat.
Zmapujte řetěz, než někoho přesunete
Pro každý klientský profil zapište šest věcí: vnější autentizační metodu, případnou vnitřní metodu, identitu serveru, kterou klient očekává, rozhraní mezi bránou a backendem, atribut, který brána mapuje na členství ve skupině, a výslednou zásadu pro prostředky. Čtení v tomto pořadí ukáže, který článek nikdo nevlastní. Každá položka má vlastníka a cutover selže na té, kterou nikdo nezkontroloval.
| 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 |
Běžné přihlášení do adresáře neprojde téměř ničím z tohoto řetězu. Prokáže, že účet existuje a heslo funguje, což je právě ta část, o níž nikdy nebylo pochyb.
Hashy mezi metodami necestují
Kompatibilitu přihlašovacích údajů je nutné zkontrolovat jednou, než se některá skupina přesune. FreeRADIUS popisuje rozdělení jasně: kontrola CHAP, kterou provádí sám server, potřebuje skutečné heslo a MS-CHAP přijímá toto heslo nebo vhodný NT materiál. Hash vytvořený pro jiný účel nesedí ani na jeden případ, ať je jakkoli silný.
Rozdíl je v tom, kdo počítá důkaz. Metoda, která ověřuje navázáním na adresář, nechá adresář zkontrolovat, co zkontrolovat umí. Metoda, která ověřuje přepočtem odpovědi na výzvu, potřebuje samotné tajemství, protože server musí provést stejný výpočet.
Kde materiál chybí, jsou poctivé možnosti podporovaný reset, nová registrace, externí ověřovací služba nebo změna metody. Dočasný export obnovitelných hesel na tomto seznamu není. Vytváří úložiště přihlašovacích údajů v otevřeném textu během nejchaotičtějšího týdne projektu a obvykle migraci přežije.
Pilotní skupina, pak změny životního cyklu
Přesuňte malou skupinu schválených identit se skutečným klientem a otestujte čtyři věci: čerstvé přihlášení, záměrně špatný přihlašovací údaj, prostředky, které relace smí dosáhnout, a prostředky, které nesmí. Zkontrolujte také identitu serveru, kterou klient přijal, protože neshoda názvu certifikátu je neviditelná, dokud někdo nepřečte klientský log.
Potom projděte změny, na kterých nasazení skutečně závisí. Změňte heslo, obnovte nebo znovu zaregistrujte certifikát a jednomu pilotnímu účtu odeberte přístup. Po každé z nich potvrďte, který ověřovač pokus obsloužil, protože relace vytvořená před cutoverem může dál fungovat a nic neprokazuje o příštím přihlášení.
Oddělte doručení profilu od přepnutí identity. Každá skupina potřebuje zamýšlený profil, svůj stav přihlašovacích údajů nebo registrace, autentizační službu, kterou má používat, a kontakt na podporu, a žádný z těchto záznamů nesmí obsahovat tajemství.
Pokud stará a nová cesta existují vedle sebe, ohraničte je koncovým datem. Automatický fallback může pustit účet přes starý přihlašovací údaj poté, co nový vlastník odebral přístup, a to je bezpečnostní regrese vydávaná za dostupnost.
Rollback nedokáže obnovit přihlašovací údaj
Vrácení cutoveru ponechá adresář přesně v tom stavu, v jakém je nyní. Resetované heslo zůstane resetované, odvolaný certifikát zůstane odvolaný a změněný formát přihlašovacích údajů zůstane změněný. To jsou události v adresáři a brána nikdy nebyla jejich zdrojem. Obnova musí být definována pro každou událost a nic z toho nesmí záviset na rekonstrukci tajemství z nekompatibilního hashe.
Udržujte administrativní cestu, která nepoužívá migrované spojení. Když nová autentizace selže, pozastavte skupinu a použijte její zdokumentovanou cestu obnovy, místo abyste oslabili autentizaci pro všechny, jen abyste stihli termín.
Když jsou skupiny pokryté, vyřaďte staré backendové přihlašovací údaje, profily a vztahy důvěry prostřednictvím jejich vlastníků. Potvrďte, že stará cesta už uživatele nepouští, a ponechte mapování identity na zásadu bez tajemství, které podpora ještě potřebuje. Migrace je hotová, když nový životní cyklus funguje a nikdo se už nedostane starou cestou, ne když se seznam účtů zdá být úplný.