Migrasie van ’n VPN-verifikasiabackend sonder hergebruik van ou hashes

Gebruikersname verskyn in die nuwe gids, die migrasie word as voltooid verklaar, en aanmeldings misluk steeds. Die poort het nog steeds ’n ondersteunde verifikasielyn en ’n korrekte magtigingsuitslag nodig, en nie een van die twee volg uit ’n gids wat nou die rekeninge bevat nie. ’n Backend-skuif is ’n oorskakeling met ’n lewensiklus, nie ’n kopieertaak nie. Die simptoom hieronder is die een wat gewoonlik die verskil uitwys.

Die simptoom: rekeninge bestaan, sessies nie

Die nuwe gids hou elke gebruikersnaam, ’n toetsbinding slaag, en die VPN-kliënt gee steeds ’n verifikasiemislukking terug. Daardie kombinasie beteken die identiteit bestaan, maar die verifikasielyn wat die poort gebruik, bereik dit nie, of bereik dit met ’n metode wat dit nie kan bevredig nie. Albei is konfigurasie, en dit is verskillende probleme.

Die eerste is loodgieterswerk: die poort wys na ’n backend wat nie antwoord nie, gebruik ’n gedeelde geheim wat die ander kant nie verwag nie, of vra ’n eienskap wat die nuwe diens nie teruggee nie. Die tweede is kriptografies: die metode vereis die oorspronklike geheim, en die nuwe stoor hou slegs ’n hash daarvan. Die foutteks lyk in albei gevalle soortgelyk, en daarom word die twee as een probleem behandel.

Om daardie twee te skei voordat rekeninge aangeraak word, spaar ’n week. Die een is ’n vraag oor roetering en vertroue, die ander is ’n besluit oor die herstel van geloofsbriewe, en om hulle te vermeng lewer veranderinge op wat niemand kan toeskryf nie.

Karteer die ketting voordat enigiemand geskuif word

Skryf ses dinge vir elke kliëntprofiel neer: die buitenste verifikasiemetode, enige binnemetode, die bedieneridentiteit wat die kliënt verwag, die koppelvlak tussen poort en backend, die eienskap wat die poort aan groeplidmaatskap karteer, en die hulpbronbeleid wat daaruit volg. Om hulle in volgorde te lees, wys watter skakel niemand besit nie. Elke item het ’n eienaar, en die oorskakeling misluk by die een wat niemand nagegaan het nie.

’n Gewone gidsaanmelding oefen byna niks van daardie ketting nie. Dit bewys die rekening bestaan en die wagwoord werk, wat die deel is wat nooit betwyfel is nie.

Hashes reis nie tussen metodes nie

Geloofsbriefversoenbaarheid moet een keer nagegaan word, voordat enige groep skuif. FreeRADIUS dokumenteer die skeiding duidelik: ’n CHAP-kontrole wat die bediener self uitvoer, het die werklike wagwoord nodig, en MS-CHAP aanvaar daardie wagwoord of geskikte NT-materiaal. ’n Hash wat vir een of ander ander doel geskep is, pas by nie een van die twee gevalle nie, hoe sterk dit ook al is.

Die onderskeid gaan oor wie die bewys bereken. ’n Metode wat verifieer deur aan die gids te bind, laat die gids kontroleer wat dit kan kontroleer. ’n Metode wat verifieer deur ’n uitdagingsantwoord te herbereken, het die geheim self nodig, want die bediener moet dieselfde berekening uitvoer.

Waar die materiaal ontbreek, is die eerlike opsies ’n ondersteunde herstel, herregistrasie, ’n eksterne verifikasiediens of ’n verandering van metode. ’n Tydelike uitvoer van herwinbare wagwoorde is nie op daardie lys nie. Dit skep ’n geloofsbriefstoor in gewone teks gedurende die mees chaotiese week van die projek, en dit oorleef gewoonlik die migrasie.

Proefgroep, dan lewensiklusveranderinge

Skuif ’n klein groep goedgekeurde identiteite met die werklike kliënt, en toets vier dinge: ’n vars aanmelding, ’n doelbewus verkeerde geloofsbrief, die hulpbronne wat die sessie mag bereik, en die hulpbronne wat dit nie mag nie. Kontroleer ook die bedieneridentiteit wat die kliënt aanvaar het, want ’n sertifikaatnaam wat nie pas nie, is onsigbaar totdat iemand die kliëntlog lees.

Oefen dan die veranderinge waarvan die ontplooiing werklik afhang. Verander ’n wagwoord, hernu of herregistreer ’n sertifikaat, en verwyder toegang van een proefrekening. Bevestig ná elkeen watter verifieerder die poging hanteer het, want ’n sessie wat voor die oorskakeling geskep is, kan aanhou werk en bewys niks oor die volgende aanmelding nie.

Skei profielaflewering van die identiteitskakelaar. Elke groep het sy beoogde profiel, sy geloofsbrief- of registrasietoestand, die verifikasiediens wat dit moet gebruik en ’n ondersteuningskontak nodig, en niks van daardie rekord mag ’n geheim bevat nie.

As ou en nuwe paaie saam bestaan, begrens hulle met ’n einddatum. ’n Outomatiese terugval kan ’n rekening deur ’n ou geloofsbrief toelaat nadat die nuwe eienaar toegang verwyder het, en dit is ’n veiligheidsregressie vermom as beskikbaarheid.

Terugrol kan nie ’n geloofsbrief herstel nie

Om die oorskakeling om te keer, laat die gids presies soos dit nou staan. ’n Herstelwagwoord bly herstel, ’n herroepe sertifikaat bly herroep, en ’n veranderde geloofsbriefformaat bly verander. Dit is gebeurtenisse in die gids, en die poort was nooit hulle bron nie. Herstel moet per gebeurtenis gedefinieer word, en niks daarvan kan afhang van die herkonstruksie van ’n geheim uit ’n onversoenbare hash nie.

Hou ’n administratiewe pad wat nie die verbinding gebruik wat gemigreer word nie. Wanneer die nuwe verifikasie misluk, pouseer die groep en gebruik sy gedokumenteerde herstelroete eerder as om verifikasie vir almal te verswak om ’n spertyd te haal.

Nadat die groepe gedek is, trek die ou backend-geloofsbriewe, profiele en vertrouensverhoudings deur hulle eienaars terug. Bevestig dat die ou pad nie meer gebruikers toelaat nie, en hou die nie-geheime kartering van identiteit na beleid wat ondersteuning steeds nodig het. ’n Migrasie is klaar wanneer die nuwe lewensiklus werk en niemand meer deur die ou pad kan inkom nie, nie wanneer die rekeninglys volledig lyk nie.