VPN-hitelesítési háttérrendszer migrálása a régi kivonatok újrafelhasználása nélkül

A felhasználónevek megjelennek az új könyvtárban, a migrációt befejezettnek nyilvánítják, a bejelentkezések mégis meghiúsulnak. Az átjárónak továbbra is támogatott hitelesítési útra és helyes engedélyezési eredményre van szüksége, és egyik sem következik egy könyvtárból, amely most tartalmazza a fiókokat. A háttérrendszer áthelyezése életciklussal járó átvágás, nem másolási feladat. Az alábbi tünet az, amely általában felfedi a különbséget.

A tünet: a fiókok léteznek, a munkamenetek nem

Az új könyvtár minden felhasználónevet tartalmaz, egy teszthozzákötés sikerül, a VPN-kliens mégis hitelesítési hibát ad vissza. Ez a kombináció azt jelenti, hogy az identitás létezik, de az átjáró által használt ellenőrzési út nem éri el, vagy olyan módszerrel éri el, amelyet nem tud kielégíteni. Mindkettő konfiguráció, és különböző problémák.

Az első vezetékezés: az átjáró olyan háttérrendszerre mutat, amely nem válaszol, olyan közös titkot használ, amelyet a másik fél nem vár, vagy olyan attribútumot kér, amelyet az új szolgáltatás nem ad vissza. A második kriptográfiai: a módszer megköveteli az eredeti titkot, az új tároló pedig csak annak kivonatát tartalmazza. A hibaüzenet mindkét esetben hasonló, ezért a kettőt egyetlen problémaként kezelik.

A kettő szétválasztása a fiókok megérintése előtt egy hetet takarít meg. Az egyik útválasztási és bizalmi kérdés, a másik a hitelesítő adatok visszaállításáról szóló döntés, és a keverésük olyan változásokat szül, amelyeket senki sem tud visszavezetni.

Térképezze fel a láncot, mielőtt bárkit áthelyez

Jegyezzen fel hat dolgot minden kliensprofilhoz: a külső hitelesítési módszert, az esetleges belső módszert, a kliens által várt kiszolgáló-identitást, az átjáró és a háttérrendszer közötti interfészt, az attribútumot, amelyet az átjáró csoporttagsághoz rendel, és az ebből következő erőforrás-szabályzatot. Sorrendben olvasva kiderül, melyik láncszemnek nincs gazdája. Minden elemnek van gazdája, és az átvágás ott hiúsul meg, amelyet senki nem ellenőrzött.

Egy közönséges könyvtári bejelentkezés szinte semmit nem jár be ebből a láncból. Azt bizonyítja, hogy a fiók létezik és a jelszó működik, vagyis éppen azt a részt, amely soha nem volt kérdéses.

A kivonatok nem utaznak a módszerek között

A hitelesítő adatok kompatibilitását egyszer ellenőrizni kell, mielőtt bármelyik csoport átkerül. A FreeRADIUS világosan leírja a szétválasztást: a kiszolgáló által maga végzett CHAP-ellenőrzéshez a tényleges jelszó kell, az MS-CHAP pedig elfogadja azt a jelszót vagy megfelelő NT-anyagot. Egy más célra készült kivonat egyik esetbe sem illik, bármilyen erős is.

A különbség azon van, ki számítja ki a bizonyítékot. Az a módszer, amely a könyvtárhoz kötődve ellenőriz, hagyja, hogy a könyvtár ellenőrizze, amit tud. Az a módszer, amely a kihívásválasz újraszámításával ellenőriz, magát a titkot igényli, mert a kiszolgálónak ugyanazt a számítást kell elvégeznie.

Ahol az anyag hiányzik, a tisztességes lehetőségek a támogatott visszaállítás, az újraregisztrálás, egy külső ellenőrző szolgáltatás vagy a módszer váltása. A helyreállítható jelszavak ideiglenes exportja nem szerepel ezen a listán. A projekt legkaotikusabb hetében hoz létre egyszerű szövegű hitelesítőadat-tárat, és általában túléli a migrációt.

Pilot csoport, majd életciklus-változások

Helyezzen át egy kis csoportot jóváhagyott identitásból a valódi klienssel, és teszteljen négy dolgot: friss bejelentkezést, szándékosan hibás hitelesítő adatot, azokat az erőforrásokat, amelyeket a munkamenet elérhet, és azokat, amelyeket nem. Ellenőrizze a kliens által elfogadott kiszolgáló-identitást is, mert a tanúsítványnév eltérése láthatatlan, amíg valaki el nem olvassa a kliens naplóját.

Ezután gyakorolja azokat a változásokat, amelyektől a bevezetés valóban függ. Módosítson egy jelszót, újítson meg vagy regisztráljon újra egy tanúsítványt, és vonja meg a hozzáférést egy pilot fióktól. Mindegyik után erősítse meg, melyik ellenőrző kezelte a kísérletet, mert az átvágás előtt létrehozott munkamenet tovább működhet, és semmit nem bizonyít a következő bejelentkezésről.

Válassza szét a profil kézbesítését az identitásváltástól. Minden csoportnak szüksége van a szándékolt profiljára, a hitelesítő adat vagy regisztráció állapotára, a használandó hitelesítési szolgáltatásra és egy támogatási kapcsolattartóra, és ezek egyike sem tartalmazhat titkot.

Ha a régi és az új útvonal egymás mellett létezik, zárja le őket egy záródátummal. Az automatikus visszaesés beengedhet egy fiókot régi hitelesítő adattal azután, hogy az új tulajdonos eltávolította a hozzáférést, és ez biztonsági regresszió rendelkezésre állásként álcázva.

A visszavonás nem állíthatja helyre a hitelesítő adatot

Az átvágás visszafordítása pontosan abban az állapotban hagyja a könyvtárat, amelyben most van. Egy visszaállított jelszó visszaállított marad, egy visszavont tanúsítvány visszavont marad, egy megváltoztatott hitelesítőadat-formátum pedig megváltoztatott marad. Ezek a könyvtár eseményei, és az átjáró soha nem volt a forrásuk. A helyreállítást eseményenként kell meghatározni, és ennek semmi része nem függhet attól, hogy egy titkot összeférhetetlen kivonatból rekonstruáljunk.

Tartson fenn olyan adminisztratív útvonalat, amely nem a migrált kapcsolatot használja. Amikor az új hitelesítés meghiúsul, szüneteltesse a csoportot, és használja a dokumentált helyreállítási útvonalát ahelyett, hogy mindenki számára gyengítené a hitelesítést egy határidő betartásáért.

Miután a csoportok le vannak fedve, a régi háttérrendszerbeli hitelesítő adatokat, profilokat és bizalmi kapcsolatokat a tulajdonosaikon keresztül vonja ki. Erősítse meg, hogy a régi útvonal már nem enged be felhasználókat, és tartsa meg a titok nélküli identitás–szabályzat leképezést, amelyre a támogatásnak még szüksége van. A migráció akkor kész, amikor az új életciklus működik, és már senki nem lép be a régi útvonalon, nem pedig akkor, amikor a fióklista teljesnek tűnik.