Eine Passwortmigration ist keine Datenbankkopie. Wenn Benutzer zwischen Identitätsanbietern wechseln, kann die Quelle häufig kein Passwort bereitstellen, das das Ziel wiederverwenden kann. Selbst wenn ein Export Passwort-Hashes enthält, ist ein für eine Plattform erzeugter Hash nicht automatisch auf einer anderen gültig.
Benutzer können ihr vorhandenes Passwort unter bestimmten Voraussetzungen ohne erzwungenen Reset behalten. Die sichere Methode hängt davon ab, was die Quelle exportieren kann, ob sie Passwörter online validieren kann, wie lange sie verfügbar bleiben kann und ob die Migration jedes Konto an eine stabile Quell-ID binden kann.
Dieser Artikel bietet ein Entscheidungsmodell für die Wahl zwischen kompatiblem Import, schrittweiser Passwortvalidierung, fortgesetzter externer Validierung und einem kontrollierten Passwort-Reset. Er konzentriert sich auf den Passwortpfad. Anwendungsprotokolle, Claims, die Registrierung für Multi-Faktor-Authentifizierung (MFA) und der vollständige Cut-over-Plan müssen weiterhin als zusammenhängende Migrationsstränge behandelt werden.
Beginnen Sie mit der Quelle, nicht mit der gewünschten Benutzererfahrung
„Kein Passwort-Reset“ ist ein wünschenswertes Ergebnis, aber noch keine Migrationsmethode. Bevor Sie einen Ansatz wählen, müssen Sie klären, was die Quelle tatsächlich unterstützt:
- Kann sie Klartextpasswörter oder eine Passwortrepräsentation exportieren, die das Ziel ausdrücklich unterstützt?
- Kann sie das aktuelle Passwort eines Benutzers über eine geschützte Validierungs-API prüfen?
- Kann diese API während einer schrittweisen Migration und des Rollback-Fensters verfügbar, überwacht und unterstützt bleiben?
- Gibt es eine stabile, unveränderliche Quell-ID des Benutzers, die dasselbe Konto trotz geänderter Anmeldekennungen bindet?
- Können Passwortänderungen und Resets konsistent bleiben, solange zwei Systeme beteiligt sind?
- Erlauben Sicherheitsrichtlinien, Verträge und Risikobewertung den Import oder die Aufbewahrung von Passwortmaterial?
Verwenden Sie E-Mail-Adresse, Telefonnummer oder Benutzername nicht als alleinigen Migrationsschlüssel. Diese Kennungen können sich ändern. Eine falsche Kontozuordnung ist schwerwiegender als ein Reset, weil sie Anmeldedaten und Zugriff an die falsche Identität binden kann.
Wählen Sie einen von vier Passwortpfaden
Unterschiedliche Benutzergruppen können unterschiedliche Pfade benötigen. Aktive Beschäftigte können beispielsweise durch Onlinevalidierung schrittweise migriert werden, während inaktive externe Konten bei ihrer Rückkehr einen Reset erhalten.
| Fähigkeit und Einschränkung der Quelle | Tragfähiger Pfad | Hauptvorteil | Hauptkosten oder -risiko |
|---|---|---|---|
| Passwörter oder eine zielkompatible Passwortrepräsentation sind verfügbar und können sicher verarbeitet werden | Kontrollierter Batchimport | Benutzer können sich sofort am Ziel authentifizieren | Export, Transport und Verarbeitung von Passwortmaterial erweitern die Sicherheitsgrenze |
| Die Quelle kann vorhandene Passwörter online validieren und während des Übergangs autoritativ bleiben | Schrittweise Migration mit Directory Connector | Aktive Benutzer wechseln bei erfolgreicher Anmeldung ohne allgemeinen Reset | Quelle und Connector bleiben bis zum Cut-over Teil des produktiven Authentifizierungspfads |
| Benutzer sind bereits in FoxIDs provisioniert und nur Passwortvalidierung, Richtlinienprüfung oder Änderungsbenachrichtigung bleiben extern | External Password API | Behält eine schmalere Integration zum Passwortspeicher oder zur Richtlinie bei | Bietet nicht denselben Ablauf für Benutzererstellung und Profilsynchronisierung wie Directory Connector |
| Es gibt weder einen sicheren kompatiblen Import noch eine zuverlässige Onlinevalidierung | Verifizierter Passwort-Reset | Erstellt ein neues Zielpasswort mit klarer Vertrauensgrenze | Benutzerkommunikation, Wiederherstellungskanäle und Supportkapazität werden entscheidend |
Die Antwort lautet daher nicht immer „beibehalten“ oder immer „zurücksetzen“. Wählen Sie für jede Benutzergruppe den am wenigsten störenden Pfad, der technisch und betrieblich weiterhin vertretbar ist.
Schrittweise Migration mit Directory Connector
Directory Connector ist das zentrale Muster von FoxIDs, wenn ein vorhandenes Verzeichnis oder ein benutzerdefiniertes Repository während des Übergangs autoritativ bleiben muss.
Wenn sich ein Benutzer mit einem Passwort anmeldet, ruft FoxIDs die Connector-API auf. Nach erfolgreicher Validierung erstellt oder aktualisiert FoxIDs den internen Benutzer anhand der zurückgegebenen Kennungen, Eigenschaften und Claims. Die Antwort enthält eine stabile directoryUserId, die den Benutzer in FoxIDs an das Quellkonto bindet, auch wenn sich E-Mail-Adresse, Telefonnummer oder Benutzername später ändern.
Dadurch entsteht ein praktischer Just-in-time-Ablauf:
- Der Benutzer meldet sich über FoxIDs mit der vorhandenen Kennung und dem Passwort an einer Anwendung an.
- FoxIDs lässt das Passwort vom Quellverzeichnis validieren.
- Der Connector gibt die stabile Quell-ID und die freigegebenen Benutzerdaten zurück.
- FoxIDs erstellt oder aktualisiert den internen Benutzer und schließt die Authentifizierung ab.
- Der Benutzer kann das vorhandene Passwort weiterverwenden, solange die Quelle autoritativ bleibt.
Standardmäßig speichert FoxIDs nach einer erfolgreichen Connector-Validierung oder einer Passwort-Lebenszyklusaktion über den Connector auch eine lokale Passwortkopie. Diese Kopie ermöglicht einen späteren geplanten Wechsel zur Passwortvalidierung in FoxIDs, ohne die Passwörter aller Benutzer zurückzusetzen, die den schrittweisen Ablauf bereits durchlaufen haben.
Die Grenze ist wichtig: Solange Directory Connector aktiviert ist, bleibt das externe Verzeichnis autoritativ. FoxIDs verwendet den gespeicherten lokalen Hash nicht als automatischen Fallback, wenn der Connector nicht verfügbar ist. Ein Connector-Ausfall ist deshalb ein Fehler im Authentifizierungspfad und keine Anweisung, die Quelle zu umgehen.
Der unten gezeigte Schalter für die Passwortrichtlinie ist eine dritte, unabhängige Entscheidung. Er steuert, ob FoxIDs ein vorgeschlagenes Passwort gegen die Richtlinie der FoxIDs Umgebung prüft, bevor der Connector aufgerufen wird. Das externe Verzeichnis bleibt für das Passwort zuständig und kann es gemäß seiner eigenen Richtlinie ablehnen. Wenn beide Prüfungen verwendet werden, müssen Anforderungen und Benutzerhinweise aufeinander abgestimmt sein.
Definieren Sie Exit-Kriterien, bevor Sie den Connector aktivieren
Eine schrittweise Migration benötigt eine Endbedingung. Legen Sie vor dem Rollout fest:
- Welche Benutzergruppen müssen sich vor dem Cut-over erfolgreich angemeldet haben?
- Wie werden inaktive Konten oder Konten von Benutzern behandelt, die nicht zurückkehren?
- Wie lange müssen Quelle und Connector für einen Rollback verfügbar bleiben?
- Bei welchen Antwortzeiten und Fehlerraten des Connectors wird der Rollout gestoppt oder zurückgenommen?
- Wie werden Konflikte bei Kennungen, fehlende Claims und deaktivierte oder gelöschte Quellkonten untersucht?
- Wann kann der Connector deaktiviert werden und FoxIDs für Passwörter autoritativ werden?
Das Speichern einer lokalen Kopie ist optional. Deaktivieren Sie es, wenn eine Richtlinie verlangt, dass die Quelle der einzige Passwortspeicher bleibt. Beachten Sie jedoch, dass dadurch der Pfad zu einem späteren Wechsel ohne Reset entfällt.
Wenn External Password API die passendere, schmalere Lösung ist
FoxIDs kann ein External Password API als Passwortprüfung für interne Benutzer konfigurieren. Es kann ein aktuelles Passwort validieren, ein neues Passwort gegen eine externe Richtlinie prüfen, ein anderes System über Passwortänderungen informieren oder diese Aufgaben kombinieren.
Verwenden Sie diese Option, wenn die Benutzer bereits in FoxIDs vorhanden sind und die verbleibende Anforderung gezielt den Passwortspeicher oder die Passwortrichtlinie betrifft. Behandeln Sie sie nicht als Ersatz für Directory Connector, wenn die Migration außerdem eine Just-in-time-Benutzererstellung, eine stabile Bindung an ein externes Verzeichnis, Profilaktualisierungen oder die Verwaltung des externen Kontolebenszyklus benötigt.
Diese Unterscheidung macht die Integrationsgrenze klar: Directory Connector steht für ein autoritatives externes Verzeichnis. External Password API steht für eine externe Abhängigkeit zur Passwortvalidierung, Richtlinienprüfung oder Benachrichtigung interner Benutzer.
Wenn ein Batchimport vertretbar ist
Ein Batchimport kann die Laufzeitabhängigkeit von der Quelle beseitigen, aber nur, wenn die Eingabe für das Ziel geeignet ist und während der gesamten Übertragung geschützt werden kann.
FoxIDs unterstützt das Hochladen interner Benutzer mit bekannten Passwörtern, mit FoxIDs kompatiblen vorberechneten Passwort-Hashes oder ohne Passwörter. Ein Hash von einer beliebigen Quellplattform kann nicht einfach als FoxIDs Hash bezeichnet werden. Prüfen Sie den genauen Algorithmus, das Salt und das Zielformat, bevor Sie entscheiden, dass ein exportierter Hash wiederverwendbar ist.
Behandeln Sie den Export von Klartextpasswörtern als Sicherheitsentscheidung und nicht als Vereinfachung. Begrenzen Sie den Zugriff, verwenden Sie einen kontrollierten Übertragungsweg, verhindern Sie, dass Passwörter in Logs oder gewöhnliche Projektdateien gelangen, überprüfen Sie die Löschung temporärer Daten und dokumentieren Sie die Freigabe. Wenn diese Verarbeitung nicht vertretbar ist, wählen Sie stattdessen Onlinevalidierung oder Reset.
Wenn ein Passwort-Reset sicherer ist
Ein Reset ist nicht zwangsläufig ein Zeichen für eine gescheiterte Migration. Er ist der ehrliche Pfad, wenn die Beibehaltung des vorhandenen Passworts das Ziel schwächen oder auf Annahmen beruhen würde, die das Team nicht verifizieren kann.
Bevorzugen Sie einen kontrollierten Reset, wenn:
- die Quelle weder eine kompatible Repräsentation exportieren noch das aktuelle Passwort online validieren kann;
- die Übertragung von Passwortmaterial zu einer nicht vertretbaren Offenlegung oder einem vertraglichen Problem führen würde;
- das Passwort in der Quelle nachweislich oder mutmaßlich kompromittiert ist;
- Konten nicht mit ausreichender Sicherheit stabilen Quellidentitäten zugeordnet werden können;
- die Quelle nicht für den erforderlichen Zeitraum der schrittweisen Migration und des Rollbacks zuverlässig bleiben kann; oder
- die Beibehaltung des alten Passworts schwächere Kontrollen im Ziel erfordern würde.
FoxIDs Benutzer können ohne Passwörter hochgeladen und aufgefordert werden, über einen per E-Mail oder SMS gesendeten Verifizierungscode ein Passwort festzulegen. Das ist nur sicher, wenn die Kennung zur Kontowiederherstellung dem vorgesehenen Benutzer gehört und der Zustellkanal die Risikoanforderungen der Organisation erfüllt. Testen Sie abgelaufene Codes, nicht erreichbare Postfächer oder Telefonnummern, doppelte Kennungen, gesperrte Konten und die Supporteskalation vor einem breiten Rollout.
Kommunizieren Sie Grund und Zeitpunkt, bevor Benutzer mit dem Reset konfrontiert werden. Trennen Sie die Sicherheitsentscheidung vom Supportplan: Ein solides Reset-Design kann betrieblich dennoch scheitern, wenn Wiederherstellungskanäle veraltet sind oder der Service Desk die anfängliche Belastung nicht bewältigen kann.
Fordern Sie Nachweise vor dem Passwort-Cut-over
Testen Sie den gewählten Pfad in einer separaten FoxIDs Umgebung und migrieren Sie zunächst eine kontrollierte Benutzergruppe. Eine erfolgreiche Anmeldung ist notwendig, aber nicht ausreichend.
| Entscheidungsbereich | Erforderlicher Nachweis vor einem breiteren Rollout |
|---|---|
| Identitätsbindung | Stabile Quell-IDs, getestete Kennungsänderungen und definierter Umgang mit Duplikaten oder fehlenden Benutzern |
| Passwortverhalten | Erfolgreiche und abgelehnte Passwörter, Ablauf für abgelaufene Passwörter, Passwortänderung/Reset und Richtlinienfehler |
| Verfügbarkeit | Überwachung von Connector oder Validierungs-API, Timeouts, Fehlerbehandlung und benannter Betriebsverantwortlicher |
| Benutzermigration | Pilotergebnisse für repräsentative aktive, inaktive, deaktivierte und eingeschränkte Konten |
| Sicherheit | Genehmigte Verarbeitung von Passwortmaterial, geschützte Secrets, Diagnoselogging ohne Passwörter und überprüfte Datenaufbewahrung |
| Cut-over | Exit-Kriterien pro Benutzergruppe, Umgang mit Benutzern ohne gespeichertes Zielpasswort, Rollback-Auslöser und Verantwortlicher für die Außerbetriebnahme der Quelle |
Halten Sie die Quelle verfügbar, bis die erforderliche Benutzergruppe migriert und das Rollback-Fenster geschlossen ist. Deaktivieren Sie den Connector nicht nur deshalb, weil der Pilot erfolgreich war. Prüfen Sie den Zielpasswortpfad für die Benutzergruppe, die nach dem Cut-over funktionieren muss, und behalten Sie für den Rest einen kontrollierten Reset-Pfad bei.
So unterstützt FoxIDs die Entscheidung
Verwenden Sie die Migrationsdokumentation, um Anwendungen, Benutzer, Passwörter, Cut-over und Rollback gemeinsam zu planen. Die Dokumentation zum Directory Connector, zum External Password API und zum Hochladen von Benutzern enthält die genauen Implementierungsdetails.
Wenn die Fähigkeiten der Quelle, Benutzergruppen oder Cut-over-Kriterien noch nicht klar sind, beschreibt FoxIDs Identity Migration, wie das Team hinter der Plattform bei der Konzeption und Durchführung der Migration helfen kann.
Fazit
Benutzer können ein vorhandenes Passwort nur behalten, wenn die Migration einen vertrauenswürdigen Validierungspfad bewahrt oder sicher ein kompatibles Zielpasswort etabliert. Directory Connector bietet häufig den am wenigsten störenden schrittweisen Pfad, hält aber die Quelle bis zu einem bewussten Cut-over im produktiven Authentifizierungsfluss.
Wählen Sie einen Reset, wenn Kompatibilität, Identitätsbindung oder sichere Verarbeitung nicht nachgewiesen werden können. Die richtige Passwortstrategie macht die autoritative Quelle, das Fehlerverhalten, die Auswirkungen auf Benutzer und die Exit-Kriterien deutlich, bevor produktiver Datenverkehr umgestellt wird.