VPN autentifikācijas aizmugursistēmas migrācija, atkārtoti neizmantojot vecos jaucējkodus

Lietotājvārdi parādās jaunajā direktorijā, migrācija tiek pasludināta par pabeigtu, un pieteikšanās joprojām neizdodas. Vārtejai joprojām ir vajadzīgs atbalstīts autentifikācijas ceļš un pareizs autorizācijas rezultāts, un neviens no tiem neizriet no direktorija, kurā tagad ir konti. Aizmugursistēmas pārvietošana ir pāreja ar dzīves ciklu, nevis kopēšanas darbs. Tālāk minētais simptoms ir tas, kas parasti atklāj atšķirību.

Simptoms: konti pastāv, sesijas ne

Jaunajā direktorijā ir katrs lietotājvārds, testa saistīšana izdodas, un VPN klients joprojām atgriež autentifikācijas kļūdu. Šāda kombinācija nozīmē, ka identitāte pastāv, bet vārtejas izmantotais pārbaudes ceļš to nesasniedz vai sasniedz ar metodi, kuru tā nevar apmierināt. Abi ir konfigurācija, un tās ir dažādas problēmas.

Pirmais ir vadu savienojums: vārteja norāda uz aizmugursistēmu, kas neatbild, izmanto kopīgu noslēpumu, kuru otra puse negaida, vai pieprasa atribūtu, kuru jaunais pakalpojums neatgriež. Otrais ir kriptogrāfisks: metode prasa sākotnējo noslēpumu, un jaunajā krātuvē ir tikai tā jaucējkods. Kļūdas teksts abos gadījumos izskatās līdzīgs, tāpēc abus uzskata par vienu problēmu.

Šo divu atdalīšana pirms kontu aizskaršanas ietaupa nedēļu. Viens ir maršrutēšanas un uzticēšanās jautājums, otrs ir lēmums par akreditācijas datu atiestatīšanu, un to sajaukšana rada izmaiņas, kuras neviens nevar attiecināt.

Kartējiet ķēdi, pirms kāds tiek pārvietots

Pierakstiet sešas lietas katram klienta profilam: ārējo autentifikācijas metodi, iespējamo iekšējo metodi, servera identitāti, kuru klients gaida, saskarni starp vārteju un aizmugursistēmu, atribūtu, kuru vārteja kartē uz grupas dalību, un izrietošo resursu politiku. Lasīšana secībā parāda, kuram posmam nav īpašnieka. Katram elementam ir atbildīgais, un pāreja neizdodas tajā, kuru neviens nepārbaudīja.

Parasta pieteikšanās direktorijā neiziet gandrīz neko no šīs ķēdes. Tā pierāda, ka konts pastāv un parole darbojas, proti, tieši to daļu, par kuru nekad nebija šaubu.

Jaucējkodi nepārvietojas starp metodēm

Akreditācijas datu saderība ir jāpārbauda vienreiz, pirms pārvieto jebkuru grupu. FreeRADIUS skaidri apraksta sadalījumu: CHAP pārbaudei, ko serveris veic pats, ir vajadzīga faktiskā parole, un MS-CHAP pieņem šo paroli vai piemērotu NT materiālu. Citam mērķim radīts jaucējkods neder nevienā gadījumā, lai cik stiprs tas būtu.

Atšķirība ir tajā, kas aprēķina pierādījumu. Metode, kas pārbauda, saistoties ar direktoriju, ļauj direktorijam pārbaudīt to, ko tas spēj pārbaudīt. Metode, kas pārbauda, pārrēķinot izaicinājuma atbildi, prasa pašu noslēpumu, jo serverim ir jāveic tas pats aprēķins.

Kur materiāla trūkst, godīgās iespējas ir atbalstīta atiestatīšana, atkārtota reģistrācija, ārējs pārbaudes pakalpojums vai metodes maiņa. Atjaunojamu paroļu pagaidu eksports šajā sarakstā neietilpst. Tas rada atklāta teksta akreditācijas datu krātuvi projekta haotiskākajā nedēļā, un tas parasti pārdzīvo migrāciju.

Pilotgrupa, pēc tam dzīves cikla izmaiņas

Pārvietojiet nelielu apstiprinātu identitāšu grupu ar īsto klientu un pārbaudiet četras lietas: svaigu pieteikšanos, tīši nepareizus akreditācijas datus, resursus, kurus sesija drīkst sasniegt, un resursus, kurus tā nedrīkst sasniegt. Pārbaudiet arī servera identitāti, kuru klients pieņēma, jo sertifikāta nosaukuma neatbilstība ir neredzama, līdz kāds izlasa klienta žurnālu.

Pēc tam izmēģiniet izmaiņas, no kurām ieviešana patiešām ir atkarīga. Nomainiet paroli, atjaunojiet vai reģistrējiet sertifikātu no jauna un atņemiet piekļuvi vienam pilotkontam. Pēc katras apstipriniet, kurš pārbaudītājs apstrādāja mēģinājumu, jo pirms pārejas izveidota sesija var turpināt darboties un neko nepierāda par nākamo pieteikšanos.

Atdaliet profila piegādi no identitātes maiņas. Katrai grupai ir vajadzīgs paredzētais profils, akreditācijas datu vai reģistrācijas stāvoklis, autentifikācijas pakalpojums, kas jāizmanto, un atbalsta kontaktpersona, un nevienā no šiem ierakstiem nedrīkst būt noslēpums.

Ja vecais un jaunais ceļš pastāv līdzās, ierobežojiet tos ar beigu datumu. Automātiska atkāpšanās var ielaist kontu ar veciem akreditācijas datiem pēc tam, kad jaunais īpašnieks ir atņēmis piekļuvi, un tā ir drošības regresija, kas maskēta kā pieejamība.

Atritināšana nevar atjaunot akreditācijas datus

Pārejas apgriešana atstāj direktoriju tieši tādu, kāds tas ir tagad. Atiestatīta parole paliek atiestatīta, atsaukts sertifikāts paliek atsaukts, un mainīts akreditācijas datu formāts paliek mainīts. Tie ir notikumi direktorijā, un vārteja nekad nav bijusi to avots. Atjaunošana ir jādefinē katram notikumam, un nekas no tā nedrīkst būt atkarīgs no noslēpuma rekonstruēšanas no nesaderīga jaucējkoda.

Saglabājiet administratīvu ceļu, kas neizmanto migrējamo savienojumu. Kad jaunā autentifikācija neizdodas, apturiet grupu un izmantojiet tās dokumentēto atjaunošanas ceļu, nevis vājiniet autentifikāciju visiem, lai ievērotu termiņu.

Kad grupas ir aptvertas, izņemiet vecos aizmugursistēmas akreditācijas datus, profilus un uzticēšanās attiecības, izmantojot to īpašniekus. Apstipriniet, ka vecais ceļš vairs neielaiž lietotājus, un saglabājiet bez noslēpumiem esošo identitātes un politikas kartējumu, kas atbalstam vēl nepieciešams. Migrācija ir pabeigta, kad jaunais dzīves cikls darbojas un neviens vairs neiekļūst pa veco ceļu, nevis tad, kad kontu saraksts izskatās pilnīgs.