Migrieren von MFA-Server zur Microsoft Entra-Multi-Faktor-Authentifizierung

Die Multi-Faktor-Authentifizierung ist wichtig für den Schutz Ihrer Infrastruktur und Ressourcen vor böswilligen Akteuren. Azure Multi-Factor Authentication-Server ist für neue Bereitstellungen nicht verfügbar und wird bald eingestellt. Kund*innen, die den MFA Server verwenden, sollten zur cloudbasierten Microsoft Entra-Multi-Faktor-Authentifizierung wechseln.

In diesem Artikel wird davon ausgegangen, dass Sie eine Hybridumgebung mit folgenden Eigenschaften nutzen:

• Sie verwenden MFA-Server für Multi-Faktor-Authentifizierung.
• Sie verwenden einen Verbund in Microsoft Entra ID mit Active Directory-Verbunddiensten (AD FS) oder einem Verbundprodukt eines anderen Identitätsanbieters.
  • Dieser Artikel ist zwar auf AD FS bezogen, für andere Identitätsanbieter gelten aber ähnliche Schritte.
• Ihr MFA-Server ist mit AD FS integriert.
• Möglicherweise verwenden manche Ihrer Anwendungen AD FS für die Authentifizierung.

Abhängig von Ihrem Ziel gibt es mehrere mögliche Endzustände bei Ihrer Migration.

Verlagern Sie wenn möglich sowohl Multi-Faktor-Authentifizierung als auch die Benutzerauthentifizierung nach Azure. Eine Schrittanleitung finden Sie unter Wechseln zur Microsoft Entra-Multi-Faktor-Authentifizierung und Microsoft Entra-Benutzerauthentifizierung.

Wenn Sie Ihre Benutzerauthentifizierung nicht verschieben können, lesen Sie die Schrittanleitung für den Wechsel zur Microsoft Entra-Multi-Faktor-Authentifizierung mit Verbund.

Voraussetzungen

• AD FS-Umgebung (erforderlich, wenn Sie vor der Migration von MFA-Server nicht alle Ihre Apps zu Microsoft Entra migrieren)
  • Upgrade auf AD FS für Windows Server 2019, Farmverhaltensebene (FBL, Farm Behavior Level) 4. Mit diesem Upgrade können Sie den Authentifizierungsanbieter auf der Grundlage der Gruppenzugehörigkeit auswählen, um einen nahtlosen Übergang für Benutzer zu ermöglichen. Es ist zwar möglich, auf Grundlage von AD FS für Windows Server 2016 FBL 3 zu migrieren, aber es ist für Benutzer nicht so nahtlos. Während der Migration und bis zu ihrem Abschuss werden Benutzer*innen aufgefordert, einen Authentifizierungsanbieter (MFA-Server oder Microsoft Entra-Multi-Faktor-Authentifizierung) auszuwählen.
• Berechtigungen
  • Die Rolle „Unternehmensadministrator“ in Active Directory, um die AD FS-Farm für die Microsoft Entra-Multi-Faktor-Authentifizierung zu konfigurieren
  • Zum Verwalten dieser Funktion ist ein globaler Administrator erforderlich.

Überlegungen für alle Migrationspfade

Die Migration von MFA-Server zur Microsoft Entra-Multi-Faktor-Authentifizierung umfasst mehr als nur das Verschieben der registrierten MFA-Telefonnummern. Der MFA-Server von Microsoft kann in viele Systeme integriert werden. Sie müssen bewerten, wie diese Systeme den MFA-Server nutzen, um dann die besten Möglichkeiten für die Integration in die Microsoft Entra-Multi-Faktor-Authentifizierung zu identifizieren.

Migrieren von MFA-Benutzerinformationen

Gängige Möglichkeiten zum Verschieben von Benutzern in Batches sind das Verschieben nach Regionen, Abteilungen oder Rollen wie etwa Administratoren. Sie sollten Benutzerkonten beginnend mit Test- und Pilotgruppen iterativ verschieben und unbedingt einen Rollbackplan bereitstellen.

Sie können mit dem Hilfsprogramm zur MFA-Server-Migration MFA-Daten, die in der lokalen Azure MFA-Server-Instanz gespeichert sind, mit der Microsoft Entra-Multi-Faktor-Authentifizierung synchronisieren und Benutzer*innen mit dem gestaffelten Rollout an Azure MFA umleiten. Mit dem gestaffelten Rollout können Sie ohne Änderungen an Ihren Domänenverbundeinstellungen testen.

Damit Benutzer das neu hinzugefügte Konto von dem alten, an den MFA-Server gebundenen Konto unterscheiden können, stellen Sie sicher, dass ein gut davon zu unterscheidender Kontoname für die mobile App auf dem MFA-Server verwendet wird. Beispielsweise wurde der Kontoname, der bei MFA-Server unter „Mobile App“ erscheint, in On-Premises-MFA-Server umbenannt. Der Kontoname auf Microsoft Authenticator ändert sich mit der nächsten Pushbenachrichtigung an den Benutzer.

Die Migration von Telefonnummern kann auch dazu führen, dass ungenutzte Nummern migriert werden, wodurch die Wahrscheinlichkeit steigt, dass Benutzer telefonbasierte MFA verwenden, anstatt sicherere Methoden wie Microsoft Authenticator im kennwortlosen Modus einzurichten. Daher wird empfohlen, dass sich alle Benutzer unabhängig vom gewählten Migrationspfad für kombinierte Sicherheitsinformationen registrieren.

Migrieren von Hardwaresicherheitsschlüsseln

Microsoft Entra ID bietet Unterstützung für OATH-Hardwaretoken. Sie können mit dem Hilfsprogramm zur MFA-Server-Migration MFA-Einstellungen zwischen MFA-Server und Microsoft Entra-Multi-Faktor-Authentifizierung synchronisieren und den gestaffelten Rollout zum Testen von Benutzermigrationen verwenden, ohne die Domänenverbundeinstellungen zu ändern.

Wenn Sie nur OATH-Hardwaretoken migrieren möchten, müssen Sie Token mithilfe einer CSV-Datei in Microsoft Entra ID hochladen. Diese wird häufig als „Seedingdatei“ bezeichnet. Die Seedingdatei enthält die geheimen Schlüssel, die Tokenseriennummern und andere erforderliche Informationen, die zum Hochladen der Token in Microsoft Entra ID erforderlich sind.

Wenn Sie nicht mehr über die Ausgangsdatei mit den geheimen Schlüsseln verfügen, ist es nicht möglich, die geheimen Schlüssel aus MFA-Server zu exportieren. Wenn Sie keinen Zugriff mehr auf die geheimen Schlüssel haben, bitten Sie Ihren Hardwareanbieter um Unterstützung.

Das Webdienst-SDK von MFA-Server kann verwendet werden, um die Seriennummer für alle OATH-Token zu exportieren, die einem bestimmten Benutzer zugewiesen sind. Verwenden Sie diese Informationen zusammen mit der Seedingdatei zum Importieren der Token in Microsoft Entra ID und zum Zuweisen des OATH-Tokens zu angegebenen Benutzer*innen basierend auf der Seriennummer. Der Benutzer muss zum Zeitpunkt des Imports auch kontaktiert werden, um OTP-Informationen vom Gerät zum Abschließen der Registrierung anzufordern. Lesen Sie das Hilfedateithema GetUserInfo>userSettings>OathTokenSerialNumber in Multi-Factor Authentication-Server auf Ihrem MFA-Server.

Weitere Migrationen

Die Entscheidung, vom MFA-Server zur Microsoft Entra-Multi-Faktor-Authentifizierung zu migrieren, öffnet die Tür für weitere Migrationen. Ob Sie weitere Migrationen durchführen, hängt von vielen Faktoren ab, insbesondere:

• Ihrer Bereitschaft, die Microsoft Entra-Authentifizierung für Benutzer*innen zu verwenden
• Ihrer Bereitschaft, Ihre Anwendungen zu Microsoft Entra ID zu migrieren

Da MFA-Server sowohl für die Anwendung als auch die Benutzerauthentifizierung wesentlich ist, sollten Sie erwägen, beide Funktionen als Teil Ihrer MFA-Migration nach Azure zu verschieben und schließlich AD FS außer Betrieb zu nehmen.

Empfehlungen:

• Verwenden Sie Microsoft Entra ID zur Authentifizierung, um stabilere Sicherheit und Governance zu ermöglichen.
• Verschieben Sie Anwendungen nach Möglichkeit in Microsoft Entra ID.

Informationen zum Auswählen der besten Benutzerauthentifizierungsmethode für Ihre Organisation finden Sie unter Wählen der richtigen Authentifizierungsmethode für Ihre Microsoft Entra-Hybrididentitätslösung. Es wird empfohlen, die Kennwort-Hash-Synchronisierung (Password Hash Synchronization, PHS) zu verwenden.

Kennwortlose Authentifizierung

Im Rahmen der Einführung von Microsoft Authenticator als zweitem Authentifizierungsfaktor für Benutzer wird empfohlen, die kennwortlose Anmeldung per Telefon im Rahmen ihrer Registrierung zu aktivieren. Weitere Informationen, einschließlich anderer kennwortloser Methoden wie FIDO2-Sicherheitsschlüsseln und Windows Hello for Business, finden Sie unter Planen einer Bereitstellung für die kennwortlose Authentifizierung mit Microsoft Entra ID.

Self-Service-Kennwortrücksetzung mit Microsoft Identity Manager

Microsoft Identity Manager (MIM) SSPR kann MFA-Server verwenden, um SMS-Einmalpasscodes als Teil des Kennwortzurücksetzungsflows einzusetzen. MIM kann nicht für die Verwendung der Microsoft Entra-Multi-Faktor-Authentifizierung konfiguriert werden. Wir empfehlen, die Umstellung Ihres SSPR-Diensts auf Microsoft Entra-SSPR zu erwägen. Die Registrierung der Benutzer*innen für die Microsoft Entra-Multi-Faktor-Authentifizierung bietet Ihnen die Gelegenheit, die kombinierte Registrierungsfunktionalität zur Registrierung für Microsoft Entra-SSPR zu nutzen.

Wenn Sie Ihren SSPR-Dienst nicht verschieben können oder MFA-Server verwenden, um MFA-Anforderungen für PAM-Szenarien (Privileged Access Management) aufzurufen, empfehlen wir ein Update auf eine alternative MFA-Option eines Drittanbieters.

RADIUS-Clients und Microsoft Entra-Multi-Faktor-Authentifizierung

MFA-Server unterstützt RADIUS, um Multi-Faktor-Authentifizierung für Anwendungen und Netzwerkgeräte zu nutzen, die das Protokoll unterstützen. Wenn Sie RADIUS mit MFA-Server verwenden, empfiehlt es sich, Clientanwendungen auf moderne Protokolle wie SAML, OpenID Connect oder OAuth in Microsoft Entra ID umzustellen. Wenn die Anwendung nicht aktualisiert werden kann, können Sie einen Netzwerkrichtlinienserver (Network Policy Server, NPS) mit der Erweiterung für die Microsoft Entra-Multi-Faktor-Authentifizierung bereitstellen. Die NPS-Erweiterung fungiert als Adapter zwischen RADIUS-basierten Anwendungen und der Microsoft Entra-Multi-Faktor-Authentifizierung, um einen zweiten Authentifizierungsfaktor bereitzustellen. Durch diesen „Adapter“ können Sie Ihre RADIUS-Clients zur Microsoft Entra-Multi-Faktor-Authentifizierung migrieren und Ihren MFA-Server außer Betrieb nehmen.

Wichtige Hinweise

Es gibt Einschränkungen bei der Verwendung von NPS für RADIUS-Clients, und es wird empfohlen, bei allen RADIUS-Clients zu erwägen, ob Sie sie auf moderne Authentifizierungsprotokolle aktualisieren können. Informieren Sie sich beim Dienstanbieter über unterstützte Produktversionen und deren Funktionen.

• Die NPS-Erweiterung verwendet keine Microsoft Entra-Richtlinien für bedingten Zugriff. Wenn Sie bei RADIUS bleiben und die NPS-Erweiterung verwenden, muss der Benutzer für alle Authentifizierungsanforderungen, die an NPS gerichtet werden, MFA ausführen.
• Benutzer*innen müssen sich für die Microsoft Entra-Multi-Faktor-Authentifizierung registrieren, damit sie die NPS-Erweiterung verwenden können. Andernfalls kann die Erweiterung den Benutzer nicht authentifizieren, Was zu Anrufen beim Helpdesk führen kann.
• Wenn die NPS-Erweiterung MFA anfordert, wird die MFA-Anforderung an die MFA-Standardmethode des Benutzers gesendet.
  • Da die Anmeldung in Anwendungen erfolgt, die nicht von Microsoft stammen, wird dem Benutzer oft keine visuelle Benachrichtigung dazu angezeigt, dass Multi-Faktor-Authentifizierung erforderlich ist und eine Anforderung an sein Gerät gesendet wurde.
  • Während der Multi-Faktor-Authentifizierungsanforderung muss der Benutzer Zugriff auf seine Standard-Authentifizierungsmethode haben, um die Erfordernis zu erfüllen. Sie können keine alternative Methode auswählen. Ihre Standard-Authentifizierungsmethode wird auch dann verwendet, wenn sie in den Richtlinien für Tenant-Authentifizierungsmethoden und Multifaktor-Authentifizierung deaktiviert ist.
  • Benutzer können ihre Standardmethode für Multi-Faktor-Authentifizierung auf der Seite „Sicherheitsinformationen“ (aka.ms/mysecurityinfo) ändern.
• Verfügbare MFA-Methoden für RADIUS-Clients werden von den Clientsystemen gesteuert, die die RADIUS-Zugriffsanforderungen senden.
  • MFA-Methoden, die Benutzereingaben erfordern, nachdem Benutzer ein Kennwort eingegeben haben, können nur mit Systemen verwendet werden, die Access-Challenge-Antworten mit RADIUS unterstützen. Eingabemethoden sind etwa OTP, Hardware-OATH-Token oder Microsoft Authenticator.
  • Einige Systeme beschränken möglicherweise die verfügbaren Methoden für Multi-Faktor-Authentifizierung auf Microsoft Authenticator-Pushbenachrichtigungen und Telefonanrufe.

Häufig verwendete RADIUS-Client-Integrationen sind etwa Anwendungen wie Remotedesktopgateways und VPN-Server. Andere können folgende sein:

• Citrix Gateway
  • Citrix Gateway unterstützt sowohl die Integration der RADIUS- und NPS-Erweiterung als auch eine SAML-Integration.
• Cisco VPN
  • Cisco VPN unterstützt sowohl die RADIUS- als auch die SAML-Authentifizierung für SSO.
  • Durch den Wechsel von der RADIUS-Authentifizierung zu SAML können Sie Cisco VPN integrieren, ohne die NPS-Erweiterung bereitzustellen.
• Alle VPNs
  • Es wird empfohlen, Ihr VPN nach Möglichkeit als SAML-App zu föderieren. Dieser Verbund ermöglicht die Verwendung von bedingtem Zugriff. Weitere Informationen erhalten Sie über die Liste von VPN-Anbietern, die im Microsoft Entra ID App-Katalog enthalten sind.

Ressourcen zum Bereitstellen von NPS

• Hinzufügen einer neuen NPS-Infrastruktur
• Bewährte Methoden vor der Bereitstellung
• Integritätsüberprüfungsskript für die NPS-Erweiterung für die Microsoft Entra-Multi-Faktor-Authentifizierung
• Integrieren der Microsoft Entra-Multi-Faktor-Authentifizierung in die vorhandene NPS-Infrastruktur

Nächste Schritte

• Wechseln zur Microsoft Entra-Multi-Faktor-Authentifizierung mit Verbund
• Wechseln zur Microsoft Entra-Multi-Faktor-Authentifizierung und Microsoft Entra-Benutzerauthentifizierung
• Verwenden des Hilfsprogramms zur MFA-Server-Migration