Migrering af en VPN-autentificeringsbackend uden genbrug af gamle hashes

Brugernavne dukker op i det nye katalog, migreringen erklæres færdig, og logins fejler alligevel. Gatewayen har stadig brug for en understøttet autentificeringsvej og et korrekt autorisationsresultat, og ingen af delene følger af et katalog, der nu indeholder konti. En backend-flytning er et skift med en livscyklus, ikke en kopieringsopgave. Symptomet nedenfor er det, der normalt afslører forskellen.

Symptomet: konti findes, sessioner gør ikke

Det nye katalog indeholder hvert brugernavn, et testbind lykkes, og VPN-klienten returnerer stadig en autentificeringsfejl. Kombinationen betyder, at identiteten findes, men at den verifikationsvej, gatewayen bruger, ikke når den, eller når den med en metode, den ikke kan opfylde. Begge er konfiguration, og de er forskellige problemer.

Det første er rørføring: gatewayen peger på en backend, der ikke svarer, bruger en delt hemmelighed, som den anden side ikke forventer, eller beder om en attribut, som den nye tjeneste ikke returnerer. Det andet er kryptografisk: metoden kræver den oprindelige hemmelighed, og det nye lager indeholder kun en hash af den. Fejlteksten ser ens ud i begge tilfælde, og derfor bliver de to behandlet som ét problem.

At skille de to ad, før man rører ved konti, sparer en uge. Det ene er et spørgsmål om routing og tillid, det andet er en beslutning om nulstilling af legitimationsoplysninger, og at blande dem giver ændringer, som ingen kan henføre.

Kortlæg kæden, før nogen flyttes

Skriv seks ting ned for hver klientprofil: den ydre autentificeringsmetode, en eventuel indre metode, den serveridentitet klienten forventer, grænsefladen mellem gateway og backend, den attribut gatewayen mapper til gruppemedlemskab, og den ressourcepolitik, der følger. At læse dem i rækkefølge viser, hvilket led ingen ejer. Hvert punkt har en ejer, og skiftet fejler ved det, som ingen kontrollerede.

Et almindeligt kataloglogin afprøver næsten intet af den kæde. Det beviser, at kontoen findes, og at adgangskoden virker, hvilket er den del, der aldrig var i tvivl.

Hashes rejser ikke mellem metoder

Kompatibilitet af legitimationsoplysninger skal kontrolleres én gang, før nogen gruppe flyttes. FreeRADIUS dokumenterer opdelingen klart: et CHAP-tjek, som serveren selv udfører, kræver den faktiske adgangskode, og MS-CHAP accepterer den adgangskode eller passende NT-materiale. En hash fremstillet til et andet formål passer i ingen af tilfældene, uanset hvor stærk den er.

Forskellen handler om, hvem der beregner beviset. En metode, der verificerer ved at binde til kataloget, lader kataloget kontrollere, hvad det kan kontrollere. En metode, der verificerer ved at genberegne et udfordringssvar, har brug for selve hemmeligheden, fordi serveren skal udføre den samme beregning.

Hvor materialet mangler, er de ærlige muligheder en understøttet nulstilling, en ny registrering, en ekstern verifikationstjeneste eller et metodeskift. En midlertidig eksport af gendannelige adgangskoder er ikke på den liste. Den skaber et lager med legitimationsoplysninger i klartekst i projektets mest kaotiske uge, og den overlever som regel migreringen.

Pilotgruppe, derefter livscyklusændringer

Flyt en lille gruppe godkendte identiteter med den rigtige klient, og test fire ting: et frisk login, en bevidst forkert legitimationsoplysning, de ressourcer sessionen må nå, og de ressourcer den ikke må. Kontrollér også den serveridentitet, klienten accepterede, fordi et navnemismatch i certifikatet er usynligt, indtil nogen læser klientloggen.

Afprøv derefter de ændringer, som udrulningen faktisk afhænger af. Skift en adgangskode, forny eller genregistrér et certifikat, og fjern adgangen fra en pilotkonto. Bekræft efter hver enkelt, hvilken verifier der håndterede forsøget, fordi en session oprettet før skiftet kan blive ved med at virke og ikke beviser noget om det næste login.

Adskil profiludlevering fra identitetsskiftet. Hver gruppe har brug for sin tilsigtede profil, sin tilstand for legitimationsoplysninger eller registrering, den autentificeringstjeneste den skal bruge og en supportkontakt, og ingen af disse oplysninger må indeholde en hemmelighed.

Hvis gamle og nye veje findes samtidig, skal de afgrænses med en slutdato. Et automatisk fallback kan lukke en konto ind via en gammel legitimationsoplysning, efter at den nye ejer har fjernet adgangen, og det er en sikkerhedsregression forklædt som tilgængelighed.

Tilbagerulning kan ikke gendanne en legitimationsoplysning

At vende skiftet om efterlader kataloget præcis, som det står nu. En nulstillet adgangskode forbliver nulstillet, et tilbagekaldt certifikat forbliver tilbagekaldt, og et ændret format for legitimationsoplysninger forbliver ændret. Det er begivenheder i kataloget, og gatewayen var aldrig deres kilde. Gendannelse skal defineres for hver begivenhed, og intet af det kan afhænge af at rekonstruere en hemmelighed ud fra en inkompatibel hash.

Behold en administrativ vej, som ikke bruger den forbindelse, der migreres. Når den nye autentificering fejler, skal gruppen sættes på pause, og dens dokumenterede gendannelsesvej bruges i stedet for at svække autentificeringen for alle for at overholde en deadline.

Når grupperne er dækket, skal de gamle backend-legitimationsoplysninger, profiler og tillidsforhold udfases gennem deres ejere. Bekræft, at den gamle vej ikke længere lukker brugere ind, og behold den ikke-hemmelige mapping fra identitet til politik, som support stadig har brug for. En migrering er færdig, når den nye livscyklus virker, og ingen kan komme ind ad den gamle vej længere, ikke når kontolisten ser komplet ud.