Migracija pozadinskog sistema za provjeru autentičnosti VPN-a bez ponovne upotrebe starih hasheva

Korisnička imena pojavljuju se u novom imeniku, migracija je proglašena dovršenom, a prijave i dalje ne uspijevaju. Pristupnik još uvijek treba podržan put provjere autentičnosti i ispravan rezultat autorizacije, a nijedno od toga ne proizlazi iz imenika koji sada sadrži račune. Premještanje pozadinskog sustava je presjek sa životnim ciklusom, a ne kopiranje. Simptom u nastavku je onaj koji obično otkrije razliku.

Simptom: računi postoje, sesije ne

Novi imenik sadrži svako korisničko ime, probno povezivanje uspijeva, a VPN klijent i dalje vraća pogrešku provjere autentičnosti. Takva kombinacija znači da identitet postoji, ali put provjere koji pristupnik koristi do njega ne dolazi ili dolazi metodom koju ne može zadovoljiti. Oboje je konfiguracija i to su različiti problemi.

Prvi je ožičenje: pristupnik pokazuje na pozadinski sustav koji ne odgovara, koristi zajedničku tajnu koju druga strana ne očekuje ili traži atribut koji nova usluga ne vraća. Drugi je kriptografski: metoda zahtijeva izvornu tajnu, a novo spremište drži samo njezin hash. Tekst pogreške u oba slučaja izgleda slično, zato se oba tretiraju kao jedan problem.

Razdvajanje njih dvaju prije diranja računa štedi tjedan. Jedno je pitanje usmjeravanja i povjerenja, drugo je odluka o resetiranju vjerodajnica, a njihovo miješanje stvara promjene koje nitko ne može pripisati.

Preslikajte lanac prije nego ikoga premjestite

Za svaki profil klijenta zapišite šest stvari: vanjsku metodu provjere autentičnosti, moguću unutarnju metodu, identitet poslužitelja koji klijent očekuje, sučelje između pristupnika i pozadinskog sustava, atribut koji pristupnik preslikava u članstvo u grupi i rezultirajuću politiku resursa. Čitanje tim redom pokazuje koja karika nema vlasnika. Svaka stavka ima vlasnika, a presjek pada na onoj koju nitko nije provjerio.

Obična prijava u imenik ne prolazi gotovo ništa od tog lanca. Dokazuje da račun postoji i da lozinka radi, što je upravo onaj dio koji nikada nije bio upitan.

Hashevi ne putuju između metoda

Kompatibilnost vjerodajnica mora se provjeriti jednom, prije nego se premjesti bilo koja skupina. FreeRADIUS jasno opisuje podjelu: provjera CHAP koju izvodi sam poslužitelj treba stvarnu lozinku, a MS-CHAP prihvaća tu lozinku ili odgovarajući NT materijal. Hash izrađen za neku drugu svrhu ne odgovara nijednom slučaju, koliko god bio jak.

Razlika je u tome tko računa dokaz. Metoda koja provjerava povezivanjem s imenikom pušta imenik da provjeri što može provjeriti. Metoda koja provjerava ponovnim izračunom odgovora na izazov treba samu tajnu, jer poslužitelj mora izvesti isti izračun.

Gdje materijal nedostaje, poštene su mogućnosti podržani reset, ponovna registracija, vanjska usluga provjere ili promjena metode. Privremeni izvoz obnovljivih lozinki nije na tom popisu. Stvara spremište vjerodajnica u čistom tekstu tijekom najkaotičnijeg tjedna projekta i obično nadživi migraciju.

Pilotna skupina, zatim promjene životnog ciklusa

Premjestite malu skupinu odobrenih identiteta sa stvarnim klijentom i isprobajte četiri stvari: svježu prijavu, namjerno pogrešnu vjerodajnicu, resurse koje sesija smije dosegnuti i resurse koje ne smije. Provjerite i identitet poslužitelja koji je klijent prihvatio, jer je nepodudarnost naziva certifikata nevidljiva dok netko ne pročita dnevnik klijenta.

Zatim isprobajte promjene o kojima implementacija stvarno ovisi. Promijenite lozinku, obnovite ili ponovno registrirajte certifikat i uklonite pristup jednom pilotnom računu. Nakon svake potvrdite koji je verifikator obradio pokušaj, jer sesija stvorena prije presjeka može nastaviti raditi i ništa ne dokazuje o sljedećoj prijavi.

Odvojite dostavu profila od prebacivanja identiteta. Svaka skupina treba svoj predviđeni profil, svoje stanje vjerodajnica ili registracije, uslugu provjere autentičnosti koju treba koristiti i kontakt za podršku, a nijedan od tih zapisa ne smije sadržavati tajnu.

Ako stari i novi put postoje paralelno, ograničite ih završnim datumom. Automatski fallback može pustiti račun kroz staru vjerodajnicu nakon što je novi vlasnik uklonio pristup, a to je sigurnosna regresija prerušena u dostupnost.

Vraćanje unatrag ne može obnoviti vjerodajnicu

Okretanje presjeka ostavlja imenik točno u stanju u kojem je sada. Resetirana lozinka ostaje resetirana, opozvani certifikat ostaje opozvan, a promijenjen format vjerodajnica ostaje promijenjen. To su događaji u imeniku i pristupnik nikada nije bio njihov izvor. Oporavak se mora definirati po događaju i ništa od toga ne smije ovisiti o rekonstrukciji tajne iz nekompatibilnog hasha.

Zadržite administrativni put koji ne koristi vezu koja se migrira. Kada nova provjera autentičnosti ne uspije, pauzirajte skupinu i upotrijebite njezin dokumentirani put oporavka umjesto da oslabite provjeru autentičnosti za sve kako biste stigli rok.

Nakon što su skupine pokrivene, povucite stare vjerodajnice pozadinskog sustava, profile i odnose povjerenja preko njihovih vlasnika. Potvrdite da stari put više ne pušta korisnike i zadržite preslikavanje identiteta u politiku bez tajni koje podrška još treba. Migracija je dovršena kada novi životni ciklus radi i nitko više ne ulazi starim putem, a ne kada popis računa izgleda potpun.