MFA-Server-Migration
In diesem Thema wird erläutert, wie MFA-Einstellungen für Microsoft Entra-Benutzer vom lokalen Azure MFA-Server zur Microsoft Entra-Multi-Faktor-Authentifizierung migriert werden.
Lösungsübersicht
Das Hilfsprogramm zur MFA-Server-Migration unterstützt die direkte Synchronisierung von Daten zur Multi-Faktor-Authentifizierung, die im lokalen Azure MFA-Server gespeichert sind, mit Microsoft Entra-Multi-Faktor-Authentifizierung. Nachdem die Authentifizierungsdaten zu Microsoft Entra ID migriert wurden, können Benutzer die cloudbasierte MFA nahtlos ausführen, ohne sich erneut registrieren oder Authentifizierungsmethoden bestätigen zu müssen. Administratoren können mit dem Hilfsprogramm zur MFA-Server-Migration für einzelne Benutzer oder Gruppen von Benutzern Tests und kontrollierte Rollouts durchführen, ohne mandantenweite Änderungen vornehmen zu müssen.
Video: Verwenden des Hilfsprogramms zur MFA-Server-Migration
Sehen Sie sich unser Video an, um einen Überblick über das Hilfsprogramm zur MFA-Server-Migration und dessen Funktionsweise zu erhalten.
Einschränkungen und Anforderungen
Das Hilfsprogramm zur MFA-Server-Migration erfordert, dass einen neuen Build der MFA-Server-Lösung auf Ihrem primären MFA-Server installiert ist. Der Build erstellt Updates für die MFA-Server-Datendatei und enthält das neue Hilfsprogramm zur MFA-Server-Migration. Sie müssen das WebSDK- oder Benutzerportal nicht aktualisieren. Durch die Installation des Updates wird die Migration nicht automatisch gestartet.
Hinweis
Das MFA Server Migration Utility kann auf einem sekundären MFA-Server ausgeführt werden. Weitere Informationen finden Sie unter Ausführen eines sekundären MFA-Servers (optional).
Das Hilfsprogramm zur MFA-Server-Migration kopiert die Daten aus der Datenbankdatei in die Benutzerobjekte in Microsoft Entra ID. Während der Migration können Benutzer mithilfe des gestaffelten Rollouts für Testzwecke für Microsoft Entra-Multi-Faktor-Authentifizierung ausgesucht werden. Mit der gestaffelten Migration können Sie ohne Änderungen an Ihren Domänenverbundeinstellungen testen. Nach Abschluss der Migrationen müssen Sie Ihre Migration abschließen, indem Sie Änderungen an den Domänenverbundeinstellungen vornehmen.
AD FS mit Windows Server 2016 oder höher ist erforderlich, um die MFA-Authentifizierung für alle von AD FS abhängigen Parteien bereitzustellen, Microsoft Entra ID und Office 365 nicht eingeschlossen.
Überprüfen Sie Ihre AD FS-Zugriffssteuerungsrichtlinien, und stellen Sie sicher, dass für keine MFA als Teil des Authentifizierungsprozesses lokal ausgeführt werden muss.
Der gestaffelte Rollout kann auf maximal 500.000 Benutzer ausgerichtet sein (10 Gruppen, die jeweils maximal 50.000 Benutzer enthalten).
Migrationsleitfaden
Eine MFA-Server-Migration umfasst im Allgemeinen die Schritte im folgenden Prozess:
Einige wichtige Punkte:
Phase 1 sollte wiederholt werden, wenn Sie Testbenutzer hinzufügen.
- Das Migrationstool verwendet Microsoft Entra-Gruppen zum Ermitteln der Benutzer, für die Authentifizierungsdaten zwischen MFA-Server und Microsoft Entra-Multi-Faktor-Authentifizierung synchronisiert werden sollen. Nachdem Benutzerdaten synchronisiert wurden, ist dieser Benutzer dann bereit, Microsoft Entra-Multi-Faktor-Authentifizierung zu verwenden.
- Mit dem gestaffelten Rollout können Sie Benutzer auch mithilfe von Microsoft Entra-Gruppen zur Microsoft Entra-Multi-Faktor-Authentifizierung umleiten. Obwohl Sie sicherlich dieselben Gruppen für beide Tools verwenden könnten, raten wir davon ab, weil Benutzer möglicherweise an Microsoft Entra-Multi-Faktor-Authentifizierung umgeleitet werden könnten, bevor das Tool ihre Daten synchronisiert hat. Sie sollten Microsoft Entra-Gruppen für die Synchronisierung von Authentifizierungsdaten durch das Hilfsprogramm zur MFA-Server-Migration einrichten, und einen anderen Satz von Gruppen für den gestaffelten Rollout, um Benutzer gezielt an Microsoft Entra-Multi-Faktor-Authentifizierung zu leiten anstatt an den lokalen MFA-Server.
Phase 2 sollte wiederholt werden, wenn Sie Ihre Benutzerbasis migrieren. Am Ende von Phase 2 sollte Ihre gesamte Benutzerbasis Microsoft Entra-Multi-Faktor-Authentifizierung für alle Workloads verwenden, die mit Microsoft Entra ID verbunden sind.
Während der vorherigen Phasen können Sie Benutzer aus den Ordnern für den gestaffelten Rollout entfernen, um sie aus dem Bereich von Microsoft Entra-Multi-Faktor-Authentifizierung zu entfernen und sie für alle MFA-Anforderungen, die von Microsoft Entra ID stammen, an Ihren lokalen Azure MFA-Server zurückleiten.
Phase 3 erfordert das Verschieben aller Clients, die sich bei dem lokalen MFA-Server (VPNs, Kennwortmanager usw.) über SAML/OAUTH bei dem Microsoft Entra-Verbund authentifizieren. Wenn moderne Authentifizierungsstandards nicht unterstützt werden, müssen Sie NPS-Server mit der installierten Erweiterung zur Microsoft Entra-Multi-Faktor-Authentifizierung einrichten. Sobald Abhängigkeiten migriert werden, sollten Benutzer nicht mehr das Benutzerportal auf dem MFA-Server verwenden, sondern ihre Authentifizierungsmethoden in Microsoft Entra ID (aka.ms/mfasetup) verwalten. Sobald Benutzer mit der Verwaltung ihrer Authentifizierungsdaten in Microsoft Entra ID beginnen, werden diese Methoden nicht wieder mit MFA-Server synchronisiert. Wenn Sie einen Rollback auf den lokalen MFA-Server ausführen, nachdem Benutzer Änderungen an ihren Authentifizierungsmethoden in Microsoft Entra ID vorgenommen haben, gehen diese Änderungen verloren. Nachdem Benutzermigrationen abgeschlossen sind, ändern Sie die Domänenverbundeinstellung federatedIdpMfaBehavior. Die Änderung weist Microsoft Entra ID an, MFA nicht mehr lokal auszuführen und alle MFA-Anforderungen unabhängig von der Gruppenmitgliedschaft mit Microsoft Entra-Multi-Faktor-Authentifizierung auszuführen.
In den folgenden Abschnitten werden die Migrationsschritte ausführlicher erläutert.
Identifizieren von Azure Multi-Factor Authentication Server-Abhängigkeiten
Wir haben hart daran gearbeitet, sicherzustellen, dass die Umstellung auf unsere cloudbasierte Lösung zur Microsoft Entra-Multi-Faktor-Authentifizierung Ihren Sicherheitsstatus beibehalten und sogar verbessert. Drei allgemeine Kategorien sollten zum Gruppieren von Abhängigkeiten verwendet werden:
Um Ihre Migration zu unterstützen, haben wir die häufig verwendeten MFA-Server-Features mit dem funktionalen Äquivalent in Microsoft Entra-Multi-Faktor-Authentifizierung für jede Kategorie abgeglichen.
MFA-Methoden
Öffnen Sie MFA-Server, und klicken Sie auf Unternehmenseinstellungen:
| MFA-Server | Multi-Faktor-Authentifizierung in Microsoft Entra |
|---|---|
| Registerkarte Allgemein | |
| Abschnitt „Benutzerstandard“ | |
| Telefonanruf (Standard) | Keine Aktion erforderlich |
| SMS (OTP)* | Keine Aktion erforderlich |
| Mobile App (Standard) | Keine Aktion erforderlich |
| Telefonanruf (PIN)* | Sprache aktivieren OTP |
| SMS (OTP + PIN)** | Keine Aktion erforderlich |
| Mobile App (PIN)* | Nummernabgleich aktivieren |
| Telefonanruf/SMS/mobile App/OATH-Tokensprache | Spracheinstellungen werden auf einen Benutzer automatisch basierend auf den Gebietsschemaeinstellungen in seinem Browser angewendet |
| Abschnitt „PIN-Standardregeln“ | Nicht anwendbar; siehe aktualisierte Methoden im vorherigen Screenshot |
| Registerkarte „Auflösung von Benutzernamen“ | Nicht zutreffend; für die Microsoft Entra-Multi-Faktor-Authentifizierung ist keine Auflösung des Benutzernamens erforderlich |
| Registerkarte „SMS“ | Nicht zutreffend; Microsoft Entra-Multi-Faktor-Authentifizierung verwendet eine Standardnachricht für SMS |
| Registerkarte „OATH-Token“ | Nicht zutreffend; Microsoft Entra-Multi-Faktor-Authentifizierung verwendet eine Standardnachricht für OATH-Token |
| Berichte | Aktivitätsberichte für Microsoft Entra-Authentifizierungsmethoden |
*Wenn eine PIN verwendet wird, um die Funktionalität zum Nachweis der Anwesenheit bereitzustellen, wird das funktionale Äquivalent oben bereitgestellt. PINs, die nicht kryptografisch an ein Gerät gebunden sind, schützen nicht ausreichend vor Szenarien, in denen ein Gerät kompromittiert wurde. Zum Schutz vor diesen Szenarien einschließlich SIM-Swapangriffen legen Sie für Benutzer gemäß Best Practices von Microsoft sicherere Methoden fest.
**Die standardmäßige Text-MFA-Umgebung bei der Multi-Faktor-Authentifizierung mit Microsoft Entra sendet Benutzern und Benutzerinnen einen Code, den sie als Teil der Authentifizierung in das Anmeldefenster eingeben müssen. Die Anforderung eines Code-Roundtrips stellt eine Funktionalität zum Nachweis der Anwesenheit bereit.
Benutzerportal
Öffnen Sie MFA-Server, und klicken Sie auf Benutzerportal:
| MFA-Server | Multi-Faktor-Authentifizierung in Microsoft Entra |
|---|---|
| Registerkarte „Einstellungen“ | |
| Benutzerportal-URL | aka.ms/mfasetup |
| Benutzerregistrierung zulassen | Siehe Kombinierte Registrierung von Sicherheitsinformationen |
| – Zur Angabe eines Ersatzanschlusses auffordern | Siehe MFA-Diensteinstellungen |
| – Zur Angabe eines OATH-Tokens von Drittanbietern auffordern | Siehe MFA-Diensteinstellungen |
| Ermöglicht Benutzern das Initiieren einer Einmalumgehung | Siehe Microsoft Entra ID TAP-Funktionalität |
| Benutzern die Auswahl der Methode ermöglichen | Siehe MFA-Diensteinstellungen |
| – Telefonanruf | Siehe Dokumentation zu Telefonanrufen |
| – SMS | Siehe MFA-Diensteinstellungen |
| – Mobile App | Siehe MFA-Diensteinstellungen |
| – OATH-Token | Siehe Dokumentation zum OATH-Token |
| Benutzern die Auswahl der Sprache ermöglichen | Spracheinstellungen werden auf einen Benutzer automatisch basierend auf den Gebietsschemaeinstellungen in seinem Browser angewendet |
| Benutzern das Aktivieren der mobilen App ermöglichen | Siehe MFA-Diensteinstellungen |
| – Gerätegrenzwert | Microsoft Entra ID-Beschränkung auf fünf kumulative Geräte (mobile App-Instanzen + Hardware-OATH-Token + Software-OATH-Token) pro Benutzer |
| Sicherheitsfragen als Alternative verwenden | Microsoft Entra ID ermöglicht Benutzern die Auswahl einer Fallback-Methode zum Authentifizierungszeitpunkt, wenn bei der ausgewählten Authentifizierungsmethode ein Fehler auftritt |
| – Zu beantwortende Fragen | Sicherheitsfragen in Microsoft Entra ID können nur für SSPR verwendet werden. Weitere Details finden Sie unter Benutzerdefinierte Sicherheitsfragen zu Microsoft Entra |
| Benutzern das Zuordnen von Drittanbieter-OATH-Token ermöglichen | Siehe Dokumentation zum OATH-Token |
| OATH-Token als Alternative verwenden | Siehe Dokumentation zum OATH-Token |
| Sitzungstimeout | |
| Registerkarte „Sicherheitsfragen“ | Sicherheitsfragen in MFA-Server wurden verwendet, um Zugriff auf das Benutzerportal zu erhalten. Microsoft Entra-Multi-Faktor-Authentifizierung unterstützt nur Sicherheitsfragen für die Self-Service-Kennwortzurücksetzung. Weitere Informationen finden Sie in der Dokumentation zu Sicherheitsfragen. |
| Registerkarte „Weitergegebene Sitzungen“ | Alle Authentifizierungsmethoden-Registrierungsflows werden von Microsoft Entra ID verwaltet und benötigen keine Konfiguration |
| Vertrauenswürdige IP-Adressen | Vertrauenswürdige IP-Adressen für Microsoft Entra ID |
Alle in MFA-Server verfügbaren MFA-Methoden müssen in Microsoft Entra-Multi-Faktor-Authentifizierung mithilfe der MFA-Diensteinstellungen aktiviert werden. Benutzer können ihre neu migrierten MFA-Methoden nicht ausprobieren, solange sie nicht aktiviert sind.
Authentifizierungsdienste
Azure MFA-Server kann durch Fungieren als Authentifizierungsproxy MFA-Funktionalität für Drittanbieterlösungen bereitstellen, die RADIUS oder LDAP verwenden. Um RADIUS- oder LDAP-Abhängigkeiten zu ermitteln, klicken Sie in MFA-Server auf die Optionen RADIUS-Authentifizierung und LDAP-Authentifizierung. Ermitteln Sie für jede dieser Abhängigkeiten, ob diese Drittanbieter die moderne Authentifizierung unterstützen. Wenn ja, sollten Sie den Verbund direkt mit Microsoft Entra ID in Betracht ziehen.
Für RADIUS-Bereitstellungen, die nicht aktualisiert werden können, müssen Sie einen NPS-Server bereitstellen und die NPS-Erweiterung der Microsoft Entra-Multi-Faktor-Authentifizierung installieren.
Für LDAP-Bereitstellungen, die nicht aktualisiert oder zu RADIUS verschoben werden können, bestimmen Sie, ob Microsoft Entra Domain Services verwendet werden können. In den meisten Fällen wurde LDAP bereitgestellt, um Inlinekennwortänderungen für Endbenutzer zu unterstützen. Sobald sie migriert wurden, können Endbenutzer ihre Kennwörter mithilfe der Self-Service-Kennwortzurücksetzung in Microsoft Entra ID verwalten.
Wenn Sie den MFA-Server-Authentifizierungsanbieter in AD FS 2.0 für Vertrauensstellungen der vertrauenden Seite außer für die Vertrauensstellung der vertrauenden Seite von Office 365 aktiviert haben, müssen Sie auf AD FS 3.0 aktualisieren oder diese vertrauenden Seiten direkt mit Microsoft Entra ID verbinden, wenn sie moderne Authentifizierungsmethoden unterstützen. Bestimmen Sie den besten Aktionsplan für jede der Abhängigkeiten.
Azure Multi-Factor Authentication Server-Datendatei sichern
Erstellen Sie eine Sicherung der MFA-Server-Datendatei, die sich unter „%Programme%\Multi-Factor Authentication-Server\Daten\PhoneFactor.pfdata“ (Standardspeicherort) auf Ihrem primären MFA-Server befindet. Stellen Sie sicher, dass Sie für den Fall, dass Sie einen Rollback ausführen müssen, eine Kopie des Installationsprogramms für Ihre aktuell installierte Version besitzen. Wenn Sie keine Kopie mehr haben, wenden Sie sich an die Kundensupportdienste.
Je nach Benutzeraktivität kann die Datendatei schnell veralten. Alle an MFA-Server nach der Sicherung über das Portal vorgenommenen Änderungen oder alle vorgenommenen Endbenutzeränderungen werden nicht erfasst. Wenn Sie einen Rollback ausführen, werden alle Änderungen, die nach diesem Punkt vorgenommen wurden, nicht wiederhergestellt.
Installieren des MFA-Server-Updates
Führen Sie das neue Installationsprogramm für den primären MFA-Server aus. Entfernen Sie einen Server vor dem Upgrade aus dem Lastenausgleich oder Austausch von Datenverkehr mit anderen MFA-Servern. Sie müssen Ihren aktuellen MFA-Server nicht deinstallieren, bevor Sie das Installationsprogramm ausführen. Das Installationsprogramm führt ein direktes Upgrade mithilfe des aktuellen Installationspfads (z. B. „C:\Programme\Multi-Factor Authentication Server“) aus. Folgen Sie der Aufforderung, das Microsoft Visual C++ 2015 Redistributable-Updatepaket zu installieren. Es werden sowohl die x86-Versionen als auch die x64-Versionen des Pakets installiert. Es ist nicht erforderlich, Updates für das Benutzerportal, Web SDK oder den AD FS-Adapter zu installieren.
Hinweis
Nachdem Sie das Installationsprogramm auf Ihrem primären Server ausgeführt haben, können sekundäre Server beginnen, Unbehandelte SB-Einträge zu protokollieren. Dies geschieht aufgrund von Schemaänderungen, die auf dem primären Server vorgenommen wurden, der von sekundären Servern nicht erkannt wird. Diese Fehler werden erwartet. In Umgebungen mit 10.000 Benutzern oder mehr kann die Anzahl der Protokolleinträge erheblich höher sein. Um dieses Problem zu verringern, können Sie die Dateigröße Ihrer MFA-Server-Protokolle erhöhen oder Ihre sekundären Server aktualisieren.
Konfigurieren des Hilfsprogramms zur MFA-Server-Migration
Öffnen Sie nach der Installation des MFA-Server-Updates eine PowerShell-Eingabeaufforderung mit erhöhten Rechten: Zeigen Sie auf das PowerShell-Symbol, klicken Sie mit der rechten Maustaste, und klicken Sie auf Als Administrator ausführen. Führen Sie das Skript „.\Configure-MultiFactorAuthMigrationUtility.ps1“ in Ihrem MFA-Server-Installationsverzeichnis (standardmäßig „C:\Programme\Multi-Factor Authentication Server“) aus.
Dieses Skript erfordert, dass Sie Anmeldeinformationen für einen Anwendungsadministrator in Ihrem Microsoft Entra-Mandanten bereitstellen. Das Skript erstellt dann eine neue Hilfsprogramm-Anwendung zur MFA-Server-Migration in Microsoft Entra ID, die zum Schreiben von Benutzer-Authentifizierungsmethoden in jedes Microsoft Entra-Benutzerobjekt verwendet wird.
Ersetzen Sie für Government Cloud-Kunden, die Migrationen durchführen möchten, „.com“-Einträge im Skript durch „.us“. Dieses Skript schreibt dann die HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl- und GraphUrl-Registrierungseinträge und weist das Migrationshilfsprogramm an, die entsprechenden GRAPH-Endpunkte zu verwenden.
Sie benötigen auch Zugriff auf die folgenden URLs:
https://graph.microsoft.com/*(oderhttps://graph.microsoft.us/*für Government Cloud-Kunden)https://login.microsoftonline.com/*(oderhttps://login.microsoftonline.us/*für Government Cloud-Kunden)
Das Skript weist Sie an, der neu erstellten Anwendung Administratoreinwilligungen zu erteilen. Navigieren Sie zur bereitgestellten URL, oder klicken Sie im Microsoft Entra Admin Center auf Anwendungsregistrierungen, suchen Sie die App Hilfsprogramm zur MFA-Server-Migration, und wählen Sie sie aus, klicken Sie auf API-Berechtigungen, und erteilen Sie dann die entsprechenden Berechtigungen.
Navigieren Sie anschließend zum Ordner „Multi-Factor Authentication Server“, und öffnen Sie die Anwendung MultiFactorAuthMigrationUtilityUI. Der folgende Bildschirm sollte angezeigt werden:
Sie haben das Migrationshilfsprogramm erfolgreich installiert.
Hinweis
Damit während der Migration keine Änderungen am Verhalten auftreten, müssen Sie, sofern Ihr MFA-Server einem MFA-Anbieter ohne Mandantenverweis zugeordnet ist, die Standard-MFA-Einstellungen (z. B. benutzerdefinierte Begrüßungen) für den zu migrierenden Mandanten so aktualisieren, dass sie den Einstellungen Ihres MFA-Anbieters entsprechen. Es wird empfohlen, dies vor der Migration von Benutzer*innen zu erledigen.
Ausführen eines sekundären MFA-Servers (optional)
Wenn Ihre MFA-Serverimplementierung eine große Anzahl von Benutzern oder einen ausgelasteten primären MFA-Server aufweist, sollten Sie die Bereitstellung eines dedizierten sekundären MFA-Servers zum Ausführen des Hilfsprogramms zur MFA-Servermigration und der Migrationssynchronisierungsdienste in Betracht ziehen. Nach dem Upgrade Ihres primären MFA-Servers führen Sie entweder ein Upgrade für einen vorhandenen sekundären Server durch oder stellen Sie einen neuen sekundären Server bereit. Der von Ihnen ausgewählte sekundäre Server sollte keinen anderen MFA-Datenverkehr verarbeiten.
Das Skript „Configure-MultiFactorAuthMigrationUtility.ps1“ sollte auf dem sekundären Server ausgeführt werden, um ein Zertifikat bei der App-Registrierung des Hilfsprogramms zur MFA-Servermigration zu registrieren. Das Zertifikat wird zum Authentifizieren bei Microsoft Graph verwendet. Das Ausführen des Migrationshilfsprogramms und der Synchronisierungsdienste auf einem sekundären MFA-Server sollte sowohl die Leistung manueller als auch automatisierter Benutzermigrationen verbessern.
Migrieren von Benutzerdaten
Durch das Migrieren von Benutzerdaten werden keine Daten aus der Multi-Factor Authentication Server-Datenbank entfernt oder darin geändert. Ebenso ändert sich dieser Prozess nicht, wenn ein Benutzer MFA ausführt. Dieser Vorgang ist eine unidirektionale Kopie von Daten vom lokalen Server in das entsprechende Benutzerobjekt in Microsoft Entra ID.
Das Hilfsprogramm zur MFA-Server-Migration zielt auf eine einzelne Microsoft Entra-Gruppe für alle Migrationsaktivitäten ab. Sie können dieser Gruppe direkt Benutzer oder andere Gruppen hinzufügen. Sie können sie während der Migration auch in Phasen hinzufügen.
Geben Sie zum Starten des Migrationsvorgangs den Namen oder GUID der Microsoft Entra-Gruppe ein, die Sie migrieren möchten. Nach Abschluss des Vorgangs drücken Sie die TAB-TASTE, oder klicken Sie außerhalb des Fensters, um mit der Suche nach der entsprechenden Gruppe zu beginnen. Alle in der Gruppe enthaltenen Benutzer*innen werden eingetragen. Bei einer großen Gruppe kann dies einige Minuten dauern.
Wenn Sie Attributdaten für einen Benutzer anzeigen möchten, markieren Sie den Benutzer, und wählen Sie Ansicht aus:
In diesem Fenster werden die Attribute für den ausgewählten Benutzer sowohl in Microsoft Entra ID als auch auf dem lokalen MFA-Server angezeigt. Sie können dieses Fenster verwenden, um anzuzeigen, wie Daten nach der Migration in ein Benutzerkonto geschrieben wurden.
Mit der Option Einstellungen können Sie die Einstellungen für den Migrationsprozess ändern:
Migrieren: Es gibt drei Optionen für die Migration der Standardauthentifizierungsmethode des Benutzers:
- Immer migrieren
- Nur migrieren, wenn dies nicht bereits in Microsoft Entra ID festgelegt ist
- Sicherste verfügbare Methode festlegen, wenn in Microsoft Entra ID noch keine festgelegt ist
Diese Optionen bieten Flexibilität beim Migrieren der Standardmethode. Darüber hinaus wird die Richtlinie für Authentifizierungsmethoden bei der Migration überprüft. Wenn die Standardmethode, die migriert wird, laut Richtlinie nicht zulässig ist, wird sie stattdessen auf die sicherste verfügbare Methode festgelegt.
Benutzerabgleich: Ermöglicht Ihnen, ein anderes lokales Active Directory-Attribut für den Abgleich des Microsoft Entra-UPN anzugeben, anstatt den Standardabgleich mit userPrincipalName zu verwenden:
- Das Hilfsprogramm für die Migration versucht einen direkten Abgleich mit dem UPN, ehe es das lokale Active Directory-Attribut verwendet.
- Wenn keine Übereinstimmung gefunden wird, ruft es eine Windows-API zum Auffinden des Microsoft Entra-UPN und zum Abrufen der SID auf, die zum Durchsuchen der Benutzerliste des MFA-Servers verwendet wird.
- Wenn die Windows-API den Benutzer nicht findet oder die SID auf MFA Server nicht gefunden wird, wird das konfigurierte Active Directory-Attribut verwendet, um den Benutzer im lokalen Active Directory zu finden, und die SID wird dann zum Durchsuchen der MFA Server-Benutzerliste verwendet.
Automatische Synchronisierung: Startet einen Hintergrunddienst, der alle Änderungen von Authentifizierungsmethoden an Benutzer im lokalen MFA-Server kontinuierlich überwacht und sie im angegebenen Zeitintervall in Microsoft Entra ID schreibt.
Synchronisierungsserver: Ermöglicht die Ausführung des MFA-Servermigrationsdiensts auf einem sekundären MFA-Server und nicht nur auf dem primären Server. Um den Migrationssynchronisierungsdienst für die Ausführung auf einem sekundären Server zu konfigurieren, muss das Skript
Configure-MultiFactorAuthMigrationUtility.ps1auf dem Server ausgeführt werden, damit ein Zertifikat bei der App-Registrierung des MFA-Servermigrationsprogramms registriert wird. Das Zertifikat wird zum Authentifizieren bei Microsoft Graph verwendet.
Der Migrationsprozess kann automatisch oder manuell sein.
Die manuellen Prozessschritte sind:
Um den Migrationsprozess für einen Benutzer oder eine Auswahl mehrerer Benutzer zu starten, halten Sie die STRG-TASTE gedrückt, während Sie die einzelnen Benutzer auswählen, die Sie migrieren möchten.
Nachdem Sie die gewünschten Benutzer ausgewählt haben, klicken Sie auf Benutzer migrieren>Ausgewählte Benutzer>OK.
Wenn Sie alle Benutzer in der Gruppe migrieren möchten, klicken Sie auf Benutzer migrieren>Alle Benutzer in der Microsoft Entra-Gruppe>OK.
Sie können Benutzer*innen migrieren, auch wenn sie unverändert sind. Standardmäßig ist im Hilfsprogramm die Option Nur geänderte Benutzer migrieren festgelegt. Klicken Sie auf Alle Benutzer migrieren, um zuvor migrierte Benutzer*innen, die unverändert sind, erneut zu migrieren. Das Migrieren unveränderter Benutzer kann beim Testen hilfreich sein, wenn ein Administrator die Azure MFA-Einstellungen eines Benutzers zurücksetzen muss und diesen erneut migrieren möchte.
Für den automatischen Prozess klicken Sie unter Einstellungen auf Automatische Synchronisierung und wählen Sie dann aus, ob alle Benutzer oder nur Mitglieder einer bestimmten Microsoft Entra-Gruppe synchronisiert werden sollen.
In der folgenden Tabelle ist die Synchronisierungslogik für die verschiedenen Methoden aufgelistet.
| Methode | Logik |
|---|---|
| Telefon | Wenn keine Erweiterung vorhanden ist, aktualisieren Sie das MFA-Telefon. Wenn eine Erweiterung vorhanden ist, aktualisieren Sie das Office-Telefon. Ausnahme: Wenn die Standardmethode „SMS“ lautet, verwerfen Sie die Erweiterung, und aktualisieren Sie das MFA-Telefon. |
| Ersatzanschluss | Wenn keine Erweiterung vorhanden ist, aktualisieren Sie das Alternate-Telefon. Wenn eine Erweiterung vorhanden ist, aktualisieren Sie das Office-Telefon. Ausnahme: Wenn sowohl „Telefon“ als auch „Ersatzanschluss“ eine Erweiterung haben, überspringen Sie „Ersatzanschluss“. |
| Mobile App | Maximal fünf Geräte werden migriert, oder nur vier, wenn der Benutzer auch über ein Hardware-OATH-Token verfügt. Wenn mehrere Geräte mit demselben Namen vorhanden sind, migrieren Sie nur das neueste. Die Geräte sind vom neuesten bis zum ältesten sortiert. Wenn Geräte bereits in Microsoft Entra ID vorhanden sind, führen Sie einen Abgleich mit dem geheimen OATH-Token-Schlüssel und ein Update durch. – Wenn keine Übereinstimmung mit dem geheimen OATH-Tokenschlüssel voliegt, führen Sie einen Abgleich mit dem Gerätetoken durch. – Falls gefunden, erstellen Sie ein Software-OATH-Token für das MFA-Server-Gerät, damit die OATH-Tokenmethode funktioniert. Benachrichtigungen funktionieren weiterhin mit dem vorhandenen Microsoft Entra-Multi-Faktor-Authentifizierungsgerät. – Falls nicht gefunden, erstellen Sie ein neues Gerät. Wenn das Hinzufügen eines neuen Geräts den Grenzwert von fünf Geräten überschreitet, wird das Gerät übersprungen. |
| OATH-Token | Wenn Geräte bereits in Microsoft Entra ID vorhanden sind, führen Sie einen Abgleich mit dem geheimen OATH-Token-Schlüssel und ein Update durch. – Wenn nicht gefunden, fügen Sie ein neues Hardware-OATH-Tokengerät hinzu. Wenn das Hinzufügen eines neuen Geräts den Grenzwert von fünf Geräten überschreitet, wird das OATH-Token übersprungen. |
MFA-Methoden werden basierend auf dem Migrierten aktualisiert, und die Standardmethode wird festgelegt. MFA Server verfolgt den letzten Migrationszeitstempel und migriert den Benutzer nur dann erneut, wenn sich die MFA-Einstellungen des Benutzers ändern, oder wenn ein Administrator im Dialogfeld Einstellungen ändert, was migriert werden soll.
Während des Tests sollten Sie zuerst eine manuelle Migration durchführen und testen, um sicherzustellen, dass sich eine bestimmte Anzahl von Benutzern wie erwartet verhält. Wenn das Testen erfolgreich ist, aktivieren Sie die automatische Synchronisierung für die Microsoft Entra-Gruppe, die Sie migrieren möchten. Während Sie dieser Gruppe Benutzer hinzufügen, werden ihre Informationen automatisch mit Microsoft Entra ID synchronisiert. Das Hilfsprogramm zur MFA-Server-Migration zielt auf eine Microsoft Entra-Gruppe ab, diese Gruppe kann jedoch sowohl Benutzer als auch geschachtelte Benutzergruppen umfassen.
Nach Abschluss erhalten Sie eine Bestätigung über die abgeschlossenen Aufgaben:
Wie in der Bestätigungsmeldung erwähnt, kann es mehrere Minuten dauern, bis die migrierten Daten in Microsoft Entra ID auf Benutzerobjekten angezeigt werden. Benutzer können ihre migrierten Methoden anzeigen, indem sie zu aka.ms/mfasetup navigieren.
Tipp
Sie können die zum Anzeigen von Gruppen erforderliche Zeit reduzieren, wenn Sie keine MFA-Methoden von Microsoft Entra anzeigen müssen. Wählen Sie Ansicht>Azure AD-MFA-Methoden aus, um die Anzeige von Spalten für AAD Default, AAD Phone, AAD Alternate, AAD Office, AAD Devices und AAD OATH Token umzuschalten. Wenn Spalten ausgeblendet sind, werden einige Microsoft Graph-API-Aufrufe übersprungen, wodurch die Ladezeit für Benutzer und Benutzerinnen erheblich reduziert wird.
Anzeigen von Migrationsdetails
Sie können Überwachungsprotokolle oder Log Analytics verwenden, um Details zu Benutzermigrationen von MFA Server zu Azure MFA anzuzeigen.
Verwenden von Überwachungsprotokollen
Führen Sie die folgenden Schritte aus, um auf die Überwachungsprotokolle im Microsoft Entra Admin Center zuzugreifen und Details zu Benutzermigrationsvorgängen von MFA Server zu Azure MFA anzuzeigen:
Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Authentifizierungsadministrator an.
Browsen Sie zu Identität>Überwachung und Integrität>Überwachungsprotokolle. Klicken Sie auf Filter hinzufügen, um die Protokolle zu filtern.
Wählen Sie Initiiert von (Akteur) aus, und klicken Sie auf Anwenden.
Geben Sie Azure MFA-Verwaltung ein, und klicken Sie auf Anwenden.
Dieser Filter zeigt nur Protokolle des MFA Server-Migrationshilfsprogramms an. Um Details für eine Benutzermigration anzuzeigen, klicken Sie auf eine Zeile, und wählen Sie dann die Registerkarte Geänderte Eigenschaften aus. Auf dieser Registerkarte werden Änderungen an registrierten MFA-Methoden und Telefonnummern angezeigt.
In der folgenden Tabelle ist die Authentifizierungsmethode für jeden Code aufgeführt.
Code Methode 0 Voice für Mobilgerät 2 Voice für Geschäftsgerät 3 Voice für alternatives Mobilgerät 5 SMS 6 Microsoft Authenticator-Pushbenachrichtigung 7 Hardware- oder Softwaretoken-OTP Wenn Benutzergeräte migriert wurden, gibt es einen separaten Protokolleintrag.
Verwenden von Log Analytics
Die Details zur Benutzermigrationen von MFA Server zu Azure MFA können auch mithilfe von Log Analytics abgefragt werden.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc
Dieser Screenshot zeigt Änderungen für die Benutzermigration:
Dieser Screenshot zeigt Änderungen für die Gerätemigration:
Log Analytics kann auch verwendet werden, um die Aktivitäten der Benutzermigration zusammenzufassen.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
Überprüfen und Testen
Nachdem Sie Benutzerdaten erfolgreich migriert haben, können Sie die Endbenutzerumgebung mithilfe des gestaffelten Rollouts überprüfen, bevor Sie die globale Mandantenänderung vornehmen. Der folgende Prozess ermöglicht Ihnen, bestimmte Microsoft Entra-Gruppen für den gestaffelten Rollout für MFA zu verwenden. Der gestaffelte Rollout weist Microsoft Entra ID an, MFA mithilfe der Microsoft Entra-Multi-Faktor-Authentifizierung für Benutzer in den Zielgruppen auszuführen, anstatt sie hierfür an den lokalen MFA-Server zu senden. Sie können überprüfen und testen – wir empfehlen die Verwendung des Microsoft Entra Admin Centers, aber wenn Sie es bevorzugen, können Sie auch Microsoft Graph verwenden.
Aktivieren des gestaffelten Rollouts
Navigieren Sie zu der folgenden URL: Aktivieren von „Gestaffelter Rollout“-Features – Microsoft Azure.
Ändern Sie Azure-Multi-Faktor-Authentifizierung in Ein, und klicken Sie dann auf Gruppen verwalten.
Klicken Sie auf Gruppen hinzufügen, und fügen Sie die Gruppen hinzu, die Benutzer enthalten, die Sie für Azure MFA aktivieren möchten. Ausgewählte Gruppen sind in der angezeigten Liste enthalten.
Hinweis
Alle Gruppen, die Sie mit der nachstehenden Microsoft Graph-Methode erreichen, werden auch in dieser Liste angezeigt.
Aktivieren des gestaffelten Rollouts mithilfe von Microsoft Graph
Erstellen der featureRolloutPolicy
Navigieren Sie zu aka.ms/ge, und melden Sie sich mit einem Hybrididentitätsadministrator-Konto in dem Mandanten, den Sie für den gestaffelten Rollout einrichten möchten, bei Graph Explorer an.
Stellen Sie sicher, dass POST für den folgenden Endpunkt ausgewählt ist:
https://graph.microsoft.com/v1.0/policies/featureRolloutPoliciesDer Text ihrer Anforderung sollte Folgendes enthalten (ändern Sie MFA-Rolloutrichtlinie in einen Namen und eine Beschreibung für Ihre Organisation):
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
Führen Sie einen GET-Befehl mit demselben Endpunkt aus, und notieren Sie sich den ID-Wert (in der folgenden Abbildung durchgestrichen):
Ausrichtung auf die Microsoft Entra-Gruppe(n), die die Benutzer enthält, die Sie testen möchten
Erstellen Sie eine POST-Anforderung mit dem folgenden Endpunkt (ersetzen Sie {ID der Richtlinie} durch den ID-Wert, den Sie aus Schritt 1d kopiert haben):
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$refDer Textkörper der Anforderung sollte Folgendes enthalten (ersetzen Sie {ID der Gruppe} durch die Objekt-ID der Gruppe, die Sie für den gestaffelten Rollout festlegen möchten):
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }Wiederholen Sie die Schritte a und b für alle anderen Gruppen, für die Sie einen gestaffelten Rollout durchführen möchten.
Sie können die aktuelle Richtlinie anzeigen, indem Sie einen GET-Befehl für folgende URL ausführen:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesToDer vorherige Vorgang verwendet die featureRolloutPolicy-Ressource. Die öffentliche Dokumentation wurde noch nicht mit dem neuen multifactorAuthentication-Feature aktualisiert, enthält jedoch detaillierte Informationen zur Interaktion mit der API.
Vergewissern Sie sich, dass die MFA-Endbenutzeroberfläche funktioniert. Sie können bspw. Folgendes überprüfen:
- Sehen Benutzer ihre Methoden in aka.ms/mfasetup?
- Empfangen Benutzer Telefonanrufe/SMS?
- Können sie sich erfolgreich mit den oben genannten Methoden authentifizieren?
- Erhalten Benutzer erfolgreich Authenticator-Benachrichtigungen? Können sie diese Benachrichtigungen genehmigen? Ist die Authentifizierung erfolgreich?
- Sind Benutzer in der Lage, sich erfolgreich mit Hardware-OATH-Token zu authentifizieren?
Schulen von Benutzern
Stellen Sie sicher, dass Benutzer wissen, was sie einschließlich neuer Authentifizierungsflüsse erwarten müssen, wenn sie in Azure MFA verschoben werden. Sie können Benutzer auch anweisen, anstelle des Benutzerportals das Microsoft Entra ID-Portal für kombinierte Registrierung (aka.ms/mfasetup) zu verwenden, um ihre Authentifizierungsmethoden zu verwalten, sobald Migrationen abgeschlossen sind. Alle Änderungen, die an Authentifizierungsmethoden in Microsoft Entra ID vorgenommen wurden, werden nicht an Ihre lokale Umgebung weitergegeben. Wenn Sie einen Rollback auf MFA-Server durchführen mussten, sind alle Änderungen, die Benutzer in Microsoft Entra ID vorgenommen haben, nicht im MFA-Server-Benutzerportal verfügbar.
Wenn Sie Drittanbieterlösungen verwenden, die zur Authentifizierung von Azure MFA-Server abhängen (siehe Authentifizierungsdienste), sollten Benutzer Änderungen an ihren MFA-Methoden weiterhin im Benutzerportal vornehmen. Diese Änderungen werden automatisch mit Microsoft Entra ID synchronisiert. Nachdem Sie diese Drittanbieter-Lösungen migriert haben, können Sie Benutzer zur Microsoft Entra ID-Seite zur kombinierten Registrierung verschieben.
Abschließen der Benutzermigration
Wiederholen Sie die Migrationsschritte aus den Abschnitten Migrieren von Benutzerdaten und Überprüfen und Testen, bis alle Benutzerdaten migriert sind.
Migrieren von MFA-Server-Abhängigkeiten
Beginnen Sie mit den Datenpunkten, die Sie in Authentifizierungsdienste gesammelt haben, mit der Durchführung der verschiedenen erforderlichen Migrationen. Sobald dies abgeschlossen ist, sollten Sie erwägen, dass Benutzer ihre Authentifizierungsmethoden anstatt im Benutzerportal auf MFA-Server im Portal zur kombinierten Registrierung verwalten.
Aktualisieren der Domänenverbundeinstellungen
Nachdem Sie Benutzermigrationen abgeschlossen und alle Authentifizierungsdienste vom MFA Server entfernt haben, sollten Sie die Einstellungen für Ihren Domänenverbund aktualisieren. Nach dem Update sendet Microsoft Entra keine MFA-Anforderung mehr an Ihren lokalen Verbundserver.
Um Microsoft Entra ID so zu konfigurieren, dass MFA-Anforderungen an Ihren lokalen Verbundserver ignoriert werden, installieren Sie das Microsoft Graph PowerShell SDK, und legen Sie federatedIdpMfaBehavior wie im folgenden Beispiel gezeigt auf rejectMfaByFederatedIdp fest.
Anforderung
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Antwort
Hinweis: Das hier gezeigte Antwortobjekt wurde möglicherweise zur besseren Lesbarkeit gekürzt.
HTTP/1.1 200 OK
Content-Type: application/json
{
"@odata.type": "#microsoft.graph.internalDomainFederation",
"id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
"issuerUri": "http://contoso.com/adfs/services/trust",
"metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
"signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"passiveSignInUri": "https://sts.contoso.com/adfs/ls",
"preferredAuthenticationProtocol": "wsFed",
"activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
"signOutUri": "https://sts.contoso.com/adfs/ls",
"promptLoginBehavior": "nativeSupport",
"isSignedAuthenticationRequestRequired": true,
"nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"signingCertificateUpdateStatus": {
"certificateUpdateResult": "Success",
"lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
},
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Benutzer werden nicht mehr an Ihren lokalen Verbundserver für MFA umgeleitet, unabhängig davon, ob das Tool für den gestaffelten Rollout auf sie angewendet wird oder nicht. Beachten Sie, dass es bis zu 24 Stunden dauern kann, bis diese Änderung in Kraft tritt.
Hinweis
Es kann bis zu 24 Stunden dauern, bis die Aktualisierung der Domänenverbundeinstellung wirksam wird.
Optional: Deaktivieren des MFA-Server-Benutzerportals
Nachdem Sie die Migration aller Benutzerdaten abgeschlossen haben, können Endbenutzer mit der Verwendung der Microsoft Entra ID-Seite für kombinierte Registrierung beginnen, um MFA-Methoden zu verwalten. Es gibt einige Möglichkeiten, Benutzer daran zu hindern, das MFA-Server-Benutzerportal zu verwenden:
- Umleiten Ihrer MFA-Server-Benutzerportal-URL an aka.ms/mfasetup
- Deaktivieren Sie das Kontrollkästchen Benutzeranmeldung zulassen auf der Registerkarte Einstellungen im Abschnitt „Benutzerportal“ von MFA Server, um grundsätzlich zu verhindern, dass sich Benutzer im Portal anmelden.
Außerbetriebnahme von MFA-Server
Wenn Sie den Azure MFA-Server nicht mehr benötigen, befolgen Sie Ihre normalen Methoden bei Außerbetriebnahme von Servern. Es ist keine besondere Aktion in Microsoft Entra ID erforderlich, um die Außerbetriebnahme von MFA-Server anzugeben.
Rollbackplan
Wenn beim Upgrade Probleme aufgetreten sind, führen Sie die folgenden Schritte aus, um den Rollback auszuführen:
Deinstallieren Sie MFA- Server 8.1.
Ersetzen Sie „PhoneFactor.pfdata“ durch die vor dem Upgrade vorgenommene Sicherung.
Hinweis
Alle seit dem Erstellen der Sicherung vorgenommenen Änderungen gehen verloren, sollten jedoch minimal sein, wenn die Sicherung direkt vor dem Upgrade durchgeführt wurden und das Upgrade nicht erfolgreich war.
Führen Sie das Installationsprogramm für Ihre vorherige Version aus (z. B. 8.0.x.x).
Konfigurieren Sie Microsoft Entra ID so, dass MFA-Anforderungen an Ihren lokalen Verbundserver akzeptiert werden. Verwenden Sie Graph PowerShell, um federatedIdpMfaBehavior auf
enforceMfaByFederatedIdpfestzulegen, wie im folgenden Beispiel gezeigt.Anforderung
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }Das folgende Antwortobjekt wird der Lesbarkeit halber gekürzt.
Antwort
HTTP/1.1 200 OK Content-Type: application/json { "@odata.type": "#microsoft.graph.internalDomainFederation", "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc", "issuerUri": "http://contoso.com/adfs/services/trust", "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex", "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "passiveSignInUri": "https://sts.contoso.com/adfs/ls", "preferredAuthenticationProtocol": "wsFed", "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed", "signOutUri": "https://sts.contoso.com/adfs/ls", "promptLoginBehavior": "nativeSupport", "isSignedAuthenticationRequestRequired": true, "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u", "signingCertificateUpdateStatus": { "certificateUpdateResult": "Success", "lastRunDateTime": "2021-08-25T07:44:46.2616778Z" }, "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }
Setzen Sie Gestaffelter Rollout für Azure MFA auf Aus. Benutzer werden erneut an Ihren lokalen Verbundserver für MFA umgeleitet.