Migration eines VPN-Authentifizierungs-Backends ohne Wiederverwendung alter Hashes

Benutzernamen erscheinen im neuen Verzeichnis, die Migration wird für abgeschlossen erklärt, und die Anmeldungen scheitern weiterhin. Das Gateway braucht nach wie vor einen unterstützten Authentifizierungspfad und ein korrektes Autorisierungsergebnis, und beides folgt nicht aus einem Verzeichnis, das die Konten nun enthält. Ein Backend-Umzug ist ein Cutover mit Lebenszyklus, kein Kopierauftrag. Das folgende Symptom ist das, welches den Unterschied meist sichtbar macht.

Das Symptom: Konten existieren, Sitzungen nicht

Das neue Verzeichnis enthält jeden Benutzernamen, ein Test-Bind gelingt, und der VPN-Client meldet weiterhin einen Authentifizierungsfehler. Diese Kombination bedeutet, dass die Identität existiert, der vom Gateway genutzte Prüfpfad sie aber nicht erreicht oder sie mit einer Methode erreicht, die sie nicht erfüllen kann. Beides ist Konfiguration, und es sind verschiedene Probleme.

Das erste ist Verkabelung: Das Gateway zeigt auf ein Backend, das nicht antwortet, verwendet ein gemeinsames Geheimnis, das die Gegenseite nicht erwartet, oder fragt ein Attribut ab, das der neue Dienst nicht liefert. Das zweite ist kryptografisch: Die Methode verlangt das ursprüngliche Geheimnis, und der neue Speicher hält nur dessen Hash. Der Fehlertext sieht in beiden Fällen ähnlich aus, weshalb die beiden als ein Problem behandelt werden.

Die beiden zu trennen, bevor Konten angefasst werden, spart eine Woche. Das eine ist eine Frage von Routing und Vertrauen, das andere eine Entscheidung über das Zurücksetzen von Zugangsdaten, und ihre Vermischung erzeugt Änderungen, die niemand zuordnen kann.

Die Kette abbilden, bevor jemand umzieht

Notieren Sie für jedes Client-Profil sechs Dinge: die äußere Authentifizierungsmethode, eine eventuelle innere Methode, die Serveridentität, die der Client erwartet, die Schnittstelle zwischen Gateway und Backend, das Attribut, das das Gateway auf Gruppenmitgliedschaft abbildet, und die daraus folgende Ressourcenrichtlinie. Sie in dieser Reihenfolge zu lesen zeigt, welches Glied niemand besitzt. Jeder Punkt hat einen Verantwortlichen, und der Cutover scheitert an dem, den niemand geprüft hat.

Eine gewöhnliche Verzeichnisanmeldung durchläuft fast nichts von dieser Kette. Sie beweist, dass das Konto existiert und das Passwort funktioniert, also gerade den Teil, der nie fraglich war.

Hashes wandern nicht zwischen Methoden

Die Kompatibilität der Zugangsdaten muss einmal geprüft werden, bevor eine Gruppe umzieht. FreeRADIUS dokumentiert die Trennung deutlich: Eine CHAP-Prüfung, die der Server selbst vornimmt, benötigt das tatsächliche Passwort, und MS-CHAP akzeptiert dieses Passwort oder geeignetes NT-Material. Ein Hash, der für einen anderen Zweck erzeugt wurde, passt auf keinen der beiden Fälle, so stark er auch sein mag.

Der Unterschied betrifft die Frage, wer den Nachweis berechnet. Eine Methode, die durch Bindung an das Verzeichnis prüft, lässt das Verzeichnis prüfen, was es prüfen kann. Eine Methode, die durch Neuberechnung einer Challenge-Antwort prüft, braucht das Geheimnis selbst, weil der Server dieselbe Berechnung ausführen muss.

Wo das Material fehlt, sind die ehrlichen Optionen ein unterstützter Reset, eine erneute Registrierung, ein externer Prüfdienst oder ein Methodenwechsel. Ein vorübergehender Export wiederherstellbarer Passwörter steht nicht auf dieser Liste. Er erzeugt einen Klartext-Speicher für Zugangsdaten in der chaotischsten Woche des Projekts, und er überlebt die Migration meist.

Pilotgruppe, dann Änderungen im Lebenszyklus

Stellen Sie eine kleine Gruppe freigegebener Identitäten mit dem echten Client um und prüfen Sie vier Dinge: eine frische Anmeldung, ein absichtlich falsches Zugangsdatum, die Ressourcen, die die Sitzung erreichen darf, und die Ressourcen, die sie nicht erreichen darf. Prüfen Sie außerdem die Serveridentität, die der Client akzeptiert hat, denn eine abweichende Zertifikatsbezeichnung bleibt unsichtbar, bis jemand das Client-Log liest.

Spielen Sie dann die Änderungen durch, von denen der Betrieb tatsächlich abhängt. Ändern Sie ein Passwort, erneuern oder registrieren Sie ein Zertifikat neu, und entziehen Sie einem Pilotkonto den Zugang. Bestätigen Sie danach jeweils, welcher Verifier den Versuch bearbeitet hat, denn eine vor dem Cutover erzeugte Sitzung kann weiterlaufen und beweist nichts über die nächste Anmeldung.

Trennen Sie die Profilauslieferung vom Identitätswechsel. Jede Gruppe braucht ihr vorgesehenes Profil, ihren Zugangsdaten- oder Registrierungsstatus, den Authentifizierungsdienst, den sie nutzen soll, und einen Ansprechpartner im Support, und keiner dieser Datensätze darf ein Geheimnis enthalten.

Wenn alter und neuer Pfad nebeneinander bestehen, begrenzen Sie sie mit einem Enddatum. Ein automatischer Rückfall kann ein Konto über alte Zugangsdaten hereinlassen, nachdem der neue Verantwortliche den Zugang entfernt hat, und das ist eine Sicherheitsregression, die sich als Verfügbarkeit tarnt.

Ein Rollback kann keine Zugangsdaten wiederherstellen

Das Umkehren des Cutovers hinterlässt das Verzeichnis genau so, wie es jetzt steht. Ein zurückgesetztes Passwort bleibt zurückgesetzt, ein widerrufenes Zertifikat bleibt widerrufen, und ein geändertes Format der Zugangsdaten bleibt geändert. Das sind Ereignisse im Verzeichnis, und das Gateway war nie ihre Quelle. Die Wiederherstellung muss pro Ereignis definiert werden, und nichts davon darf davon abhängen, ein Geheimnis aus einem inkompatiblen Hash zu rekonstruieren.

Halten Sie einen administrativen Weg frei, der nicht die migrierte Verbindung nutzt. Wenn die neue Authentifizierung scheitert, halten Sie die Gruppe an und nutzen Sie ihren dokumentierten Wiederherstellungsweg, statt die Authentifizierung für alle zu schwächen, um einen Termin zu halten.

Nachdem die Gruppen abgedeckt sind, ziehen Sie die alten Backend-Zugangsdaten, Profile und Vertrauensbeziehungen über ihre Verantwortlichen zurück. Bestätigen Sie, dass der alte Pfad keine Benutzer mehr einlässt, und behalten Sie die nicht geheime Zuordnung von Identität zu Richtlinie, die der Support noch braucht. Eine Migration ist fertig, wenn der neue Lebenszyklus funktioniert und niemand mehr über den alten Pfad hereinkommt, nicht wenn die Kontoliste vollständig aussieht.