Konfigurieren von Azure Multi-Factor Authentication-Server für Hochverfügbarkeit
Um hohe Verfügbarkeit bei Ihrer für Azure MFA Server-Bereitstellung zu erreichen, müssen Sie mehrere MFA-Server bereitstellen. Dieser Abschnitt enthält Informationen zu einem Entwurf mit Lastenausgleich, mit dem Sie Ihre Hochverfügbarkeitsziele für die Azure MFS Server-Bereitstellung erreichen können.
Wichtig
Im September 2022 hat Microsoft angekündigt, dass die Unterstützung von Microsoft Azure Multi-Factor Authentication-Server eingestellt wird. Ab dem 30. September 2024 werden Bereitstellungen von Azure Multi-Factor Authentication-Server keine Anforderungen für die Multi-Faktor-Authentifizierung mehr bedienen. Dies könnte dazu führen, dass bei Authentifizierungen in Ihrer Organisation Fehler auftreten. Um unterbrechungsfreie Authentifizierungsdienste sicherzustellen und in einem unterstützten Zustand zu verbleiben, sollten Organisationen mithilfe des neuesten Migrationshilfsprogramms, das im aktuellsten Azure MFA-Server-Update enthalten ist, die Authentifizierungsdaten ihrer Benutzer zum cloudbasierten Azure MFA-Dienst migrieren. Weitere Informationen finden Sie unter Azure MFA-Server-Migration.
Informationen zu den ersten Schritten mit der cloudbasierten MFA finden Sie unter Tutorial: Schützen von Benutzeranmeldeereignissen mit der Multi-Faktor-Authentifizierung von Microsoft Entra.
Übersicht über MFA Server
Die Dienstarchitektur von Azure MFA Server umfasst mehrere Komponenten, die im folgenden Diagramm dargestellt sind:
Ein MFA-Server ist ein Windows-Server, auf dem die Software für die Azure-Multi-Faktor-Authentifizierung installiert ist. Die MFA Server-Instanz muss vom MFA-Dienst in Azure aktiviert werden. Sie können lokal auch mehrere MFA Server-Instanzen installieren.
Der erste installierte MFA-Server wird nach der Aktivierung durch den Azure MFA-Dienst standardmäßig zum primären MFA-Server. Der primäre MFA-Server verfügt über eine beschreibbare Kopie der Datenbank „PhoneFactor.pfdata“. Alle danach installierten Instanzen von MFA Server werden als untergeordnete Server bezeichnet. Auf den untergeordneten MFA-Servern befindet sich eine replizierte schreibgeschützte Kopie der Datenbank „PhoneFactor.pfdata“. MFA-Server replizieren ihre Informationen mithilfe von Remoteprozeduraufrufen (RPC). Alle MFA-Server müssen gemeinsam einer Domäne angehören oder eigenständig sein, um Informationen zu replizieren.
Sowohl der primäre MFA- als auch der untergeordnete MFA-Server kommuniziert mit dem MFA-Dienst, wenn eine zweistufige Authentifizierung erforderlich ist. Wenn z.B. ein Benutzer versucht, Zugriff auf eine Anwendung zu erhalten, die eine zweistufige Authentifizierung erfordert, wird der Benutzer zunächst von einem Identitätsanbieter wie Active Directory (AD) authentifiziert.
Nach der erfolgreichen Authentifizierung in AD kommuniziert der MFA-Server mit dem MFA-Dienst. Der MFA-Server wartet auf eine Benachrichtigung vom MFA-Dienst, um den Benutzerzugriff auf die Anwendung zuzulassen oder zu verweigern.
Wenn der primäre MFA-Server offline geschaltet wird, können Authentifizierungen weiterhin verarbeitet werden, Vorgänge, die Änderungen an der MFA-Datenbank erfordern, jedoch nicht. (Beispiele: Hinzufügen von Benutzern, Self-Service-PIN-Änderungen, Ändern von Benutzerinformationen oder Zugreifen auf das Benutzerportal)
Bereitstellung
Berücksichtigen Sie die folgenden wichtigen Punkte für den Lastenausgleich von Azure MFA Server und den zugehörigen Komponenten.
Verwenden des RADIUS-Standards für Hochverfügbarkeit: Wenn Sie Server mit Azure MFA Server als RADIUS-Server verwenden, können Sie potenziell einen MFA-Server als primäres RADIUS-Authentifizierungsziel und andere Azure MFA Server-Instanzen als sekundäre Authentifizierungsziele konfigurieren. Allerdings ist diese Methode für Hochverfügbarkeit möglicherweise nicht sehr effizient, da Sie, wenn auf dem primären Authentifizierungsziel ein Authentifizierungsfehler auftritt, ein Timeout abwarten müssen, bevor Sie eine Authentifizierung mit den sekundären Authentifizierungszielen durchführen können. Effizienter ist ein Lastenausgleich für den RADIUS-Datenverkehr zwischen dem RADIUS-Client und den RADIUS-Servern (in diesem Fall die Azure MFA-Server, die als RADIUS-Server fungieren). In diesem Fall können Sie die RADIUS-Clients mit einer einzelnen URL konfigurieren, auf die sie verweisen können.
Manuelles Höherstufen untergeordneter MFA-Server: Wenn der primäre Azure MFA-Server offline geschaltet wird, verarbeiten die sekundären Azure MFA Server-Instanzen weiterhin MFA-Anforderungen. Bis ein primärer MFA-Server verfügbar ist, können Administratoren allerdings keine Benutzer hinzufügen oder MFA-Einstellungen ändern, und Benutzer können keine Änderungen über das Benutzerportal vornehmen. Das Höherstufen eines untergeordneten MFA-Servers auf die primäre Rolle ist immer ein manueller Vorgang.
Trennbarkeit von Komponenten: Azure MFA Server besteht aus mehreren Komponenten, die auf derselben Windows Server-Instanz oder auf verschiedenen Instanzen installiert werden können. Zu diesen Komponenten gehören das Benutzerportal, der Webdienst für Mobile Apps und der AD FS-Adapter (Agent). Diese Trennbarkeit ermöglicht die Verwendung des Webanwendungsproxys, um das Benutzerportal und den Webserver für Mobile App aus dem Umkreisnetzwerk zu veröffentlichen. Eine solche Konfiguration erhöht die allgemeine Sicherheit Ihres Entwurfs. Dies wird im folgenden Diagramm dargestellt. Das MFA-Benutzerportal und der Webserver für Mobile Apps können auch in Hochverfügbarkeitskonfigurationen mit Lastenausgleich bereitgestellt werden.
Die Verwendung von Einmalkennwörtern per SMS (auch als Einmal-SMS bezeichnet) erfordert die Verwendung von persistenten Sitzungen, wenn für den Datenverkehr ein Lastenausgleich verwendet wird. Einmal-SMS ist eine Authentifizierungsoption, bei der der MFA-Server den Benutzern eine Textnachricht (SMS) mit einem Einmalkennwort sendet. Der Benutzer gibt das Einmalkennwort in einem Eingabeaufforderungsfenster ein, um die MFA-Anforderung zu erfüllen. Wenn Sie einen Lastenausgleich für Azure MFA Server vornehmen, muss der gleiche Server, der die anfängliche Authentifizierunganforderung verarbeitet, auch der Server sein, der die Nachricht mit dem Einmalkennwort von den Benutzern erhält. Wenn ein anderer MFA-Server die Antwort auf das Einmalkennwort empfängt, führt die Authentifizierungsaufforderung zu einem Fehler. Weitere Informationen finden Sie unter One Time Password over SMS Added to Azure MFA Server (Einmalkennwort per SMS jetzt in Azure MFA Server).
Bereitstellungen von Benutzerportal und Webdienst für Mobile Apps mit Lastenausgleich erfordern persistente Sitzungen: Wenn Sie einen Lastenausgleich für das MFA-Benutzerportal und den Webdienst für Mobile Apps vornehmen, muss jede Sitzung auf demselben Server bleiben.
Bereitstellung mit hoher Verfügbarkeit
Das folgende Diagramm zeigt eine vollständige Hochverfügbarkeitsimplementierung von Azure MFA und den zugehörigen Komponenten mit Lastenausgleich zusammen mit AD FS als Referenz.
Beachten Sie die folgenden Elemente für den entsprechend nummerierten Bereich im Diagramm oben.
Für die beiden Azure MFA Server-Instanzen (MFA1 und MFA2) wird ein Lastenausgleich (mfaapp.contoso.com) vorgenommen. Außerdem ist für die Replikation der Datenbank „PhoneFactor.pfdata“ die Verwendung eines statischen Ports konfiguriert (4443). Das Webdienst-SDK ist auf jedem der MFA-Server installiert, um die Kommunikation über TCP-Port 443 mit den AD FS-Servern zu ermöglichen. Die MFA-Server werden in einer zustandslosen Konfiguration mit Lastenausgleich bereitgestellt. Wenn Sie allerdings Einmalkennwörter per SMS verwenden möchten, müssen Sie einen zustandsbehafteten Lastenausgleich verwenden.
Hinweis
Da für RPC dynamische Ports verwendet werden, sollten Firewalls nicht bis in den Bereich der dynamischen Ports, den RPC potenziell verwenden kann, geöffnet werden. Wenn Sie über eine Firewall zwischen Ihren MFA-Anwendungsservern verfügen, sollten Sie die MFA-Server für die Kommunikation des Replikationsdatenverkehrs zwischen untergeordneten Servern und primären Servern über einen statischen Port konfigurieren und diesen Port in Ihrer Firewall öffnen. Sie können den statischen Port erzwingen, indem Sie einen DWORD-Registrierungswert unter
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactorerstellen, der den NamenPfsvc_ncan_ip_tcp_porthat, und den Wert auf einen verfügbaren statischen Port festlegen. Verbindungen werden immer von den untergeordneten MFA-Servern an den primären Server initiiert. Der statische Port ist also nur auf dem primären Server erforderlich. Da Sie aber jederzeit einen untergeordneten Server zum primären Server hochstufen können, sollten Sie den statischen Port auf allen MFA-Servern festlegen.Für die beiden Server für Benutzerportal und MFA Mobile App (MFA-UP-MAS1 und MFA-UP-MAS2) wird in einer zustandsbehafteten Konfiguration (mfa.contoso.com) ein Lastenausgleich vorgenommen. Beachten Sie, dass für einen Lastenausgleich von MFA-Benutzerportal und Mobile App-Dienst persistente Sitzungen eine Voraussetzung sind.
Für die AD FS-Serverfarm wird ein Lastenausgleich vorgenommen, und sie wird über AD FS-Proxys mit Lastenausgleich im Umkreisnetzwerk im Internet veröffentlicht. Jeder AD FS-Server verwendet den AD FS-Agent für die Kommunikation mit Azure MFA-Servern über eine einzige Lastenausgleichs-URL (mfaapp.contoso.com) über TCP-Port 443.