Migrere ein VPN-autentiseringsbackend utan å bruke gamle hashar på nytt

Brukarnamn dukkar opp i den nye katalogen, migreringa blir erklært ferdig, og påloggingane feilar likevel. Gatewayen treng framleis ein støtta autentiseringsveg og eit korrekt autorisasjonsresultat, og ingen av delane følgjer av ein katalog som no inneheld kontoane. Ei backendflytting er ein overgang med ein livssyklus, ikkje ein kopijobb. Symptomet nedanfor er det som vanlegvis avdekkjer skilnaden.

Symptomet: kontoar finst, sesjonar gjer det ikkje

Den nye katalogen inneheld kvart brukarnamn, ein testbind lykkast, og VPN-klienten returnerer framleis ein autentiseringsfeil. Kombinasjonen tyder at identiteten finst, men at verifiseringsvegen gatewayen brukar ikkje når han, eller når han med ein metode han ikkje kan oppfylle. Begge er konfigurasjon, og dei er ulike problem.

Det første er kabling: gatewayen peikar på ein backend som ikkje svarar, brukar ein delt løyndom som den andre sida ikkje ventar, eller spør etter ein attributt den nye tenesta ikkje returnerer. Det andre er kryptografisk: metoden krev den opphavlege løyndomen, og det nye lageret har berre ein hash av han. Feilteksten ser lik ut i begge tilfelle, og difor blir dei to handsama som eitt problem.

Å skilje dei to før kontoar blir rørte sparar ei veke. Det eine er eit spørsmål om ruting og tillit, det andre er ei avgjerd om å nullstille påloggingsinformasjon, og å blande dei gir endringar ingen kan tilskrive.

Kartlegg kjeda før nokon blir flytt

Skriv ned seks ting for kvar klientprofil: den ytre autentiseringsmetoden, ein eventuell indre metode, serveridentiteten klienten ventar, grensesnittet mellom gateway og backend, attributten gatewayen mappar til gruppemedlemskap, og ressursregelen som følgjer. Å lese dei i rekkefølgje viser kva lenkje ingen eig. Kvart punkt har ein eigar, og overgangen feilar ved det ingen kontrollerte.

Ei vanleg katalogpålogging prøver nesten ingenting av den kjeda. Ho beviser at kontoen finst og at passordet verkar, som er den delen som aldri var tvilsam.

Hashar reiser ikkje mellom metodar

Kompatibiliteten til påloggingsinformasjon må kontrollerast éin gong, før noka gruppe blir flytt. FreeRADIUS dokumenterer delinga tydeleg: ein CHAP-kontroll som serveren utfører sjølv krev det faktiske passordet, og MS-CHAP godtek det passordet eller eigna NT-materiale. Ein hash laga for eit anna føremål passar i ingen av tilfella, uansett kor sterk han er.

Skilnaden handlar om kven som reknar ut beviset. Ein metode som verifiserer ved å binde til katalogen, lèt katalogen kontrollere det han kan kontrollere. Ein metode som verifiserer ved å rekne ut eit utfordringssvar på nytt, treng løyndomen sjølv, fordi serveren må utføre den same utrekninga.

Der materialet manglar, er dei ærlege alternativa ei støtta nullstilling, ny registrering, ei ekstern verifiseringsteneste eller eit metodebyte. Ein mellombels eksport av gjenopprettbare passord står ikkje på den lista. Han lagar eit lager av påloggingsinformasjon i klartekst i den mest kaotiske veka i prosjektet, og det overlever vanlegvis migreringa.

Pilotgruppe, deretter livssyklusendringar

Flytt ei lita gruppe godkjende identitetar med den ekte klienten, og test fire ting: ei fersk pålogging, ein med vilje feil påloggingsinformasjon, ressursane sesjonen kan nå, og ressursane han ikkje kan nå. Kontroller òg serveridentiteten klienten godtok, fordi eit avvikande sertifikatnamn er usynleg til nokon les klientloggen.

Prøv deretter endringane utrullinga faktisk er avhengig av. Bytt eit passord, forny eller registrer eit sertifikat på nytt, og fjern tilgangen frå éin pilotkonto. Stadfest etter kvar av dei kva verifier som handsama forsøket, fordi ein sesjon oppretta før overgangen kan halde fram med å verke og beviser ingenting om neste pålogging.

Skil profilleveringa frå identitetsbytet. Kvar gruppe treng den tiltenkte profilen sin, tilstanden sin for påloggingsinformasjon eller registrering, autentiseringstenesta ho skal bruke og ein supportkontakt, og ingen av desse opplysningane skal innehalde ein løyndom.

Viss gamle og nye vegar lever side om side, avgrens dei med ein sluttdato. Ein automatisk tilbakefall kan sleppe inn ein konto via gammal påloggingsinformasjon etter at den nye eigaren har fjerna tilgangen, og det er ein sikkerheitsregresjon forkledd som tilgjenge.

Ei tilbakerulling kan ikkje gjenopprette påloggingsinformasjon

Å snu overgangen lèt katalogen stå nøyaktig slik han står no. Eit nullstilt passord blir verande nullstilt, eit tilbakekalla sertifikat blir verande tilbakekalla, og eit endra format for påloggingsinformasjon blir verande endra. Det er hendingar i katalogen, og gatewayen var aldri kjelda deira. Gjenoppretting må definerast per hending, og ingen av det kan henge saman med å rekonstruere ein løyndom frå ein inkompatibel hash.

Hald ein administrativ veg som ikkje brukar sambandet som blir migrert. Når den nye autentiseringa feilar, set gruppa på pause og bruk den dokumenterte gjenopprettingsvegen i staden for å svekkje autentiseringa for alle for å halde ein frist.

Når gruppene er dekte, avvikle dei gamle backend-opplysningane, profilane og tillitsforholda gjennom eigarane deira. Stadfest at den gamle vegen ikkje lenger slepp inn brukarar, og behald den ikkje-løyndomen koplinga frå identitet til regel som support framleis treng. Ei migrering er ferdig når den nye livssyklusen verkar og ingen lenger kan kome inn via den gamle vegen, ikkje når kontolista ser komplett ut.