Migrere en VPN-autentiseringsbackend uten å gjenbruke gamle hasher

Brukernavn dukker opp i den nye katalogen, migreringen erklæres ferdig, og påloggingene feiler likevel. Gatewayen trenger fortsatt en støttet autentiseringsvei og et korrekt autorisasjonsresultat, og ingen av delene følger av en katalog som nå inneholder kontoene. En backendflytting er en overgang med en livssyklus, ikke en kopijobb. Symptomet nedenfor er det som vanligvis avslører forskjellen.

Symptomet: kontoer finnes, sesjoner gjør det ikke

Den nye katalogen inneholder hvert brukernavn, en testbind lykkes, og VPN-klienten returnerer fortsatt en autentiseringsfeil. Kombinasjonen betyr at identiteten finnes, men at verifiseringsveien gatewayen bruker ikke når den, eller når den med en metode den ikke kan oppfylle. Begge er konfigurasjon, og de er forskjellige problemer.

Det første er kabling: gatewayen peker på en backend som ikke svarer, bruker en delt hemmelighet som den andre siden ikke forventer, eller spør etter en attributt den nye tjenesten ikke returnerer. Det andre er kryptografisk: metoden krever den opprinnelige hemmeligheten, og det nye lageret har bare en hash av den. Feilteksten ser lik ut i begge tilfeller, og derfor behandles de to som ett problem.

Å skille de to før kontoer røres sparer en uke. Det ene er et spørsmål om ruting og tillit, det andre er en beslutning om å tilbakestille påloggingsinformasjon, og å blande dem gir endringer ingen kan tilskrive.

Kartlegg kjeden før noen flyttes

Skriv ned seks ting for hver klientprofil: den ytre autentiseringsmetoden, en eventuell indre metode, serveridentiteten klienten forventer, grensesnittet mellom gateway og backend, attributten gatewayen mapper til gruppemedlemskap, og ressursregelen som følger. Å lese dem i rekkefølge viser hvilken lenke ingen eier. Hvert punkt har en eier, og overgangen feiler ved det ingen kontrollerte.

En vanlig katalogpålogging prøver nesten ingenting av den kjeden. Den beviser at kontoen finnes og at passordet virker, som er den delen som aldri var tvilsom.

Hasher reiser ikke mellom metoder

Kompatibiliteten til påloggingsinformasjon må kontrolleres én gang, før noen gruppe flyttes. FreeRADIUS dokumenterer delingen tydelig: en CHAP-kontroll som serveren utfører selv krever det faktiske passordet, og MS-CHAP godtar det passordet eller egnet NT-materiale. En hash laget for et annet formål passer i ingen av tilfellene, uansett hvor sterk den er.

Forskjellen handler om hvem som beregner beviset. En metode som verifiserer ved å binde til katalogen, lar katalogen kontrollere det den kan kontrollere. En metode som verifiserer ved å regne ut et utfordringssvar på nytt, trenger hemmeligheten selv, fordi serveren må utføre den samme beregningen.

Der materialet mangler, er de ærlige alternativene en støttet tilbakestilling, ny registrering, en ekstern verifiseringstjeneste eller et metodebytte. En midlertidig eksport av gjenopprettbare passord står ikke på den listen. Den lager et lager med påloggingsinformasjon i klartekst i prosjektets mest kaotiske uke, og det overlever vanligvis migreringen.

Pilotgruppe, deretter livssyklusendringer

Flytt en liten gruppe godkjente identiteter med den ekte klienten, og test fire ting: en fersk pålogging, en med vilje feil påloggingsinformasjon, ressursene sesjonen kan nå, og ressursene den ikke kan nå. Kontroller også serveridentiteten klienten godtok, fordi et avvikende sertifikatnavn er usynlig til noen leser klientloggen.

Prøv deretter endringene utrullingen faktisk avhenger av. Bytt et passord, forny eller registrer et sertifikat på nytt, og fjern tilgangen fra én pilotkonto. Bekreft etter hver av dem hvilken verifier som håndterte forsøket, fordi en sesjon opprettet før overgangen kan fortsette å virke og beviser ingenting om neste pålogging.

Skill profilleveringen fra identitetsbyttet. Hver gruppe trenger sin tiltenkte profil, sin tilstand for påloggingsinformasjon eller registrering, autentiseringstjenesten den skal bruke og en supportkontakt, og ingen av disse opplysningene skal inneholde en hemmelighet.

Hvis gamle og nye veier lever side om side, avgrens dem med en sluttdato. En automatisk tilbakefall kan slippe inn en konto via gammel påloggingsinformasjon etter at den nye eieren har fjernet tilgangen, og det er en sikkerhetsregresjon forkledd som tilgjengelighet.

En tilbakerulling kan ikke gjenopprette påloggingsinformasjon

Å snu overgangen etterlater katalogen nøyaktig slik den står nå. Et tilbakestilt passord forblir tilbakestilt, et tilbakekalt sertifikat forblir tilbakekalt, og et endret format for påloggingsinformasjon forblir endret. Det er hendelser i katalogen, og gatewayen var aldri kilden deres. Gjenoppretting må defineres per hendelse, og ingenting av det kan avhenge av å rekonstruere en hemmelighet fra en inkompatibel hash.

Hold en administrativ vei som ikke bruker forbindelsen som migreres. Når den nye autentiseringen feiler, sett gruppen på pause og bruk den dokumenterte gjenopprettingsveien i stedet for å svekke autentiseringen for alle for å holde en frist.

Når gruppene er dekket, avvikle de gamle backend-opplysningene, profilene og tillitsforholdene gjennom eierne deres. Bekreft at den gamle veien ikke lenger slipper inn brukere, og behold den ikke-hemmelige koblingen fra identitet til regel som support fortsatt trenger. En migrering er ferdig når den nye livssyklusen virker og ingen lenger kan komme inn via den gamle veien, ikke når kontolisten ser komplett ut.