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:

• MFA-Methoden
• Benutzerportal
• Authentifizierungsdienste

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:

^*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:

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.

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/* (oder https://graph.microsoft.us/* für Government Cloud-Kunden)
• https://login.microsoftonline.com/* (oder https://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.

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.ps1 auf 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:

1. 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.

2. Nachdem Sie die gewünschten Benutzer ausgewählt haben, klicken Sie auf Benutzer migrieren>Ausgewählte Benutzer>OK.

3. Wenn Sie alle Benutzer in der Gruppe migrieren möchten, klicken Sie auf Benutzer migrieren>Alle Benutzer in der Microsoft Entra-Gruppe>OK.

4. 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.

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.

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:

1. Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Authentifizierungsadministrator an.

2. Browsen Sie zu Identität>Überwachung und Integrität>Überwachungsprotokolle. Klicken Sie auf Filter hinzufügen, um die Protokolle zu filtern.

   

3. Wählen Sie Initiiert von (Akteur) aus, und klicken Sie auf Anwenden.

   

4. Geben Sie Azure MFA-Verwaltung ein, und klicken Sie auf Anwenden.

   

5. 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

6. 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

1. Navigieren Sie zu der folgenden URL: Aktivieren von „Gestaffelter Rollout“-Features – Microsoft Azure.

2. Ändern Sie Azure-Multi-Faktor-Authentifizierung in Ein, und klicken Sie dann auf Gruppen verwalten.

   

3. 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

1. Erstellen der featureRolloutPolicy

   1. 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.

   2. Stellen Sie sicher, dass POST für den folgenden Endpunkt ausgewählt ist: https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies

   3. Der 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
      }
      

      

   4. Führen Sie einen GET-Befehl mit demselben Endpunkt aus, und notieren Sie sich den ID-Wert (in der folgenden Abbildung durchgestrichen):

      

2. Ausrichtung auf die Microsoft Entra-Gruppe(n), die die Benutzer enthält, die Sie testen möchten

   1. 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/$ref

   2. Der 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}"
      }
      

   3. Wiederholen Sie die Schritte a und b für alle anderen Gruppen, für die Sie einen gestaffelten Rollout durchführen möchten.

   4. 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=appliesTo

      Der 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.

3. Vergewissern Sie sich, dass die MFA-Endbenutzeroberfläche funktioniert. Sie können bspw. Folgendes überprüfen:

   1. Sehen Benutzer ihre Methoden in aka.ms/mfasetup?
   2. Empfangen Benutzer Telefonanrufe/SMS?
   3. Können sie sich erfolgreich mit den oben genannten Methoden authentifizieren?
   4. Erhalten Benutzer erfolgreich Authenticator-Benachrichtigungen? Können sie diese Benachrichtigungen genehmigen? Ist die Authentifizierung erfolgreich?
   5. 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.

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:

1. Deinstallieren Sie MFA- Server 8.1.

2. 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.

3. Führen Sie das Installationsprogramm für Ihre vorherige Version aus (z. B. 8.0.x.x).

4. Konfigurieren Sie Microsoft Entra ID so, dass MFA-Anforderungen an Ihren lokalen Verbundserver akzeptiert werden. Verwenden Sie Graph PowerShell, um federatedIdpMfaBehavior auf enforceMfaByFederatedIdp festzulegen, 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.

Nächste Schritte

• Übersicht über das Migrieren von MFA-Server zur Microsoft Entra-Multi-Faktor-Authentifizierung
• Migrieren zur Cloudauthentifizierung mithilfe eines gestaffelten Rollouts