Een VPN-authenticatiebackend migreren zonder oude hashes te hergebruiken

Gebruikersnamen staan in de nieuwe directory, de migratie wordt als voltooid verklaard, en aanmeldingen mislukken alsnog. De gateway heeft nog steeds een ondersteund authenticatiepad en een correct autorisatieresultaat nodig, en geen van beide volgt uit een directory die de accounts nu bevat. Een backendverhuizing is een cutover met een levenscyclus, geen kopieertaak. Het symptoom hieronder is het symptoom dat het verschil meestal blootlegt.

Het symptoom: accounts bestaan, sessies niet

De nieuwe directory bevat elke gebruikersnaam, een testbind slaagt, en de VPN-client geeft nog steeds een authenticatiefout terug. Die combinatie betekent dat de identiteit bestaat, maar dat het verificatiepad dat de gateway gebruikt die niet bereikt, of die bereikt met een methode waaraan niet kan worden voldaan. Beide zijn configuratie, en het zijn verschillende problemen.

Het eerste is bekabeling: de gateway wijst naar een backend die niet antwoordt, gebruikt een gedeeld geheim dat de andere kant niet verwacht, of vraagt om een attribuut dat de nieuwe dienst niet teruggeeft. Het tweede is cryptografisch: de methode vereist het oorspronkelijke geheim, en de nieuwe opslag bevat alleen een hash daarvan. De fouttekst lijkt in beide gevallen op elkaar, en daarom worden de twee als één probleem behandeld.

Die twee scheiden voordat er aan accounts wordt geraakt, scheelt een week. Het ene is een vraag over routering en vertrouwen, het andere een beslissing over het resetten van inloggegevens, en ze door elkaar halen levert wijzigingen op die niemand kan herleiden.

Breng de keten in kaart voordat iemand verhuist

Schrijf voor elk clientprofiel zes dingen op: de buitenste authenticatiemethode, een eventuele binnenmethode, de serveridentiteit die de client verwacht, de interface tussen gateway en backend, het attribuut dat de gateway op groepslidmaatschap afbeeldt, en het resulterende resourcebeleid. Ze in volgorde lezen laat zien welke schakel niemand bezit. Elk item heeft een eigenaar, en de cutover faalt bij degene die niemand heeft gecontroleerd.

Een gewone directoryaanmelding doorloopt bijna niets van die keten. Ze bewijst dat het account bestaat en het wachtwoord werkt, en dat is juist het deel dat nooit twijfelachtig was.

Hashes reizen niet tussen methoden

Compatibiliteit van inloggegevens moet één keer worden gecontroleerd, voordat er een groep verhuist. FreeRADIUS documenteert de splitsing duidelijk: een CHAP-controle die de server zelf uitvoert, heeft het werkelijke wachtwoord nodig, en MS-CHAP accepteert dat wachtwoord of geschikt NT-materiaal. Een hash die voor een ander doel is gemaakt, past bij geen van beide gevallen, hoe sterk die ook is.

Het onderscheid gaat over wie het bewijs berekent. Een methode die verifieert door aan de directory te binden, laat de directory controleren wat die kan controleren. Een methode die verifieert door een challenge-respons opnieuw te berekenen, heeft het geheim zelf nodig, omdat de server dezelfde berekening moet uitvoeren.

Waar het materiaal ontbreekt, zijn de eerlijke opties een ondersteunde reset, opnieuw inschrijven, een externe verificatiedienst of een wijziging van methode. Een tijdelijke export van herstelbare wachtwoorden staat niet op die lijst. Die creëert een opslag van inloggegevens in platte tekst in de meest chaotische week van het project, en die overleeft de migratie meestal.

Pilotgroep, dan wijzigingen in de levenscyclus

Verplaats een kleine groep goedgekeurde identiteiten met de echte client, en test vier dingen: een verse aanmelding, een opzettelijk verkeerde inloggegevens, de resources die de sessie mag bereiken, en de resources die ze niet mag bereiken. Controleer ook de serveridentiteit die de client heeft geaccepteerd, want een afwijkende certificaatnaam blijft onzichtbaar tot iemand het clientlog leest.

Doorloop daarna de wijzigingen waarvan de uitrol werkelijk afhangt. Wijzig een wachtwoord, vernieuw of herinschrijf een certificaat, en verwijder de toegang van één pilotaccount. Bevestig na elk daarvan welke verifier het verzoek heeft afgehandeld, want een sessie die vóór de cutover is gemaakt kan blijven werken en bewijst niets over de volgende aanmelding.

Scheid de profieluitgifte van de identiteitsoverstap. Elke groep heeft zijn beoogde profiel nodig, zijn status van inloggegevens of inschrijving, de authenticatiedienst die hij moet gebruiken en een supportcontact, en geen van die gegevens mag een geheim bevatten.

Als oude en nieuwe paden naast elkaar bestaan, begrens ze dan met een einddatum. Een automatische terugval kan een account via oude inloggegevens binnenlaten nadat de nieuwe eigenaar de toegang heeft verwijderd, en dat is een beveiligingsregressie vermomd als beschikbaarheid.

Een rollback kan geen inloggegevens herstellen

Het terugdraaien van de cutover laat de directory precies zoals die nu staat. Een gereset wachtwoord blijft gereset, een ingetrokken certificaat blijft ingetrokken, en een gewijzigd formaat van inloggegevens blijft gewijzigd. Dat zijn gebeurtenissen in de directory, en de gateway was er nooit de bron van. Herstel moet per gebeurtenis worden gedefinieerd, en niets daarvan mag afhangen van het reconstrueren van een geheim uit een incompatibele hash.

Houd een administratief pad aan dat niet de verbinding gebruikt die wordt gemigreerd. Wanneer de nieuwe authenticatie faalt, pauzeer de groep en gebruik het gedocumenteerde herstelpad in plaats van de authenticatie voor iedereen te verzwakken om een deadline te halen.

Nadat de groepen zijn afgedekt, trek je de oude backend-inloggegevens, profielen en vertrouwensrelaties via hun eigenaren in. Bevestig dat het oude pad geen gebruikers meer toelaat, en houd de niet-geheime koppeling van identiteit aan beleid die support nog nodig heeft. Een migratie is klaar wanneer de nieuwe levenscyclus werkt en niemand meer via het oude pad binnenkomt, niet wanneer de lijst met accounts compleet lijkt.