Migrieren zur Multi-Faktor-Authentifizierung mit Verbund von Microsoft Entra

Das Verschieben Ihrer MFA-Lösung (Multi-Faktor-Authentifizierung) zu Microsoft Entra ID ist ein idealer erster Schritt beim Wechsel zur Cloud. In Zukunft sollten Sie auch eine Umstellung auf Microsoft Entra ID für die Benutzerauthentifizierung in Betracht ziehen. Weitere Informationen finden Sie in der Anleitung für die Migration zur Multi-Faktor-Authentifizierung von Microsoft Entra mit Cloudauthentifizierung.

Um zur Multi-Faktor-Authentifizierung mit Verbund von Microsoft Entra zu migrieren, wird der Anbieter der Multi-Faktor-Authentifizierung von Microsoft Entra auf AD FS installiert. Die Microsoft Entra ID-Vertrauensstellung der vertrauenden Seite und andere Vertrauensstellungen vertrauender Seiten sind so konfiguriert, dass sie die Multi-Faktor-Authentifizierung von Microsoft Entra für migrierte Benutzer verwendenden.

Das folgende Diagramm zeigt den Migrationsprozess.

Flow chart of the migration process. Process areas and headings in this document are in the same order

Erstellen von Migrationsgruppen

Um neue Richtlinien für den bedingten Zugriff zu erstellen, müssen Sie diese Richtlinien Gruppen zuweisen. Hierzu können Sie Microsoft Entra-Sicherheitsgruppen oder Microsoft 365-Gruppen verwenden. Sie können auch neue erstellen oder synchronisieren.

Sie benötigen auch eine Microsoft Entra-Sicherheitsgruppe für die iterative Migration von Benutzern zur Multi-Faktor-Authentifizierung von Microsoft Entra. Diese Gruppen werden in Ihren Anspruchsregeln verwendet.

Verwenden Sie keine Gruppen, die zu Sicherheitszwecken erstellt wurden. Verwenden Sie eine Sicherheitsgruppe, die Sie zum Schützen einer Gruppe von hochwertigen Apps mit einer Richtlinie für bedingten Zugriff verwenden, nur für diesen Zweck.

Vorbereiten von AD FS

Upgrade der AD FS-Serverfarm auf 2019, FBL 4

In AD FS 2019 können Sie zusätzliche Authentifizierungsmethoden für eine vertrauende Partei angeben, z. B. eine Anwendung. Sie verwenden die Gruppenmitgliedschaft, um den Authentifizierungsanbieter zu bestimmen. Wenn Sie eine zusätzliche Authentifizierungsmethode angeben, können Sie zur Microsoft Entra-Multi-Faktor-Authentifizierung wechseln und die andere Authentifizierung während des Übergangs beibehalten. Weitere Informationen finden Sie unter Aktualisieren auf AD FS unter Windows Server 2016 unter Verwendung einer WID-Datenbank. Der Artikel behandelt sowohl das Upgrade Ihrer Farm auf AD FS 2019 als auch das Upgrade Ihrer FBL auf 4.

Konfigurieren von Anspruchsregeln zum Aufrufen der Multi-Faktor-Authentifizierung von Microsoft Entra

Da die Multi-Faktor-Authentifizierung von Microsoft Entra nun eine zusätzliche Authentifizierungsmethode ist, können Sie Benutzergruppen zuweisen, die sie verwenden sollen. Konfigurieren Sie hierzu Anspruchsregeln, die auch als Vertrauensstellungen der vertrauenden Seite bezeichnet werden. Mithilfe von Gruppen können Sie steuern, welcher Authentifizierungsanbieter global oder je nach Anwendung aufgerufen wird. Beispielsweise können Sie die Multi-Faktor-Authentifizierung von Microsoft Entra für Benutzer aufrufen, die sich für kombinierte Sicherheitsinformationen registriert haben, während für nicht registrierte Benutzer der MFA-Server aufgerufen wird.

Hinweis

Anspruchsregeln erfordern eine lokale Sicherheitsgruppe. Bevor Sie Änderungen an Anspruchsregeln vornehmen, erstellen Sie eine Sicherungskopie.

Sichern von Regeln

Sichern Sie ihre Regeln, bevor Sie neue Anspruchsregeln konfigurieren. Sie müssen diese Regeln im Rahmen der Bereinigung wiederherstellen.

Je nach Konfiguration müssen Sie möglicherweise auch die Regel kopieren und die neuen Regeln anfügen, die für die Migration erstellt werden.

Zum Anzeigen globaler Regeln führen Sie folgenden Befehl aus:

Get-AdfsAdditionalAuthenticationRule

Führen Sie zum Anzeigen von Vertrauensstellungen der vertrauenden Seite den folgenden Befehl aus, und ersetzen Sie „RPTrustName“ durch den Namen der Anspruchsregel für die Vertrauensstellung der vertrauenden Seite:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules 

Zugriffssteuerungsrichtlinien

Hinweis

Zugriffssteuerungsrichtlinien können nicht so konfiguriert werden, dass auf Grundlage der Gruppenmitgliedschaft ein bestimmter Authentifizierungsanbieter aufgerufen wird.

Um von Zugriffssteuerungsrichtlinien zu zusätzlichen Authentifizierungsregeln zu wechseln, führen Sie den folgenden Befehl für jede Ihrer Vertrauensstellungen der vertrauenden Seite mithilfe des MFA-Server-Authentifizierungsanbieters aus:

Set-AdfsRelyingPartyTrust -TargetName AppA -AccessControlPolicyName $Null

Mit diesem Befehl wird die Logik aus Ihrer aktuellen Zugriffssteuerungsrichtlinie in zusätzliche Authentifizierungsregeln verschoben.

Einrichten der Gruppe und Suchen der SID

Sie benötigen eine bestimmte Gruppe, in der Sie Benutzer platzieren, für die die Multi-Faktor-Authentifizierung von Microsoft Entra aufgerufen werden soll. Sie benötigen die Sicherheits-ID (SID) für diese Gruppe.

Um die Gruppen-SID zu ermitteln, verwenden Sie den folgenden Befehl mit dem Namen der Gruppe:

Get-ADGroup "GroupName"

Image of screen shot showing the results of the Get-ADGroup script.

Festlegen der Anspruchsregeln zum Aufrufen der Multi-Faktor-Authentifizierung von Microsoft Entra

Die folgenden PowerShell-Cmdlets rufen die Multi-Faktor-Authentifizierung von Microsoft Entra für Benutzer in der Gruppe auf, wenn diese sich nicht im Unternehmensnetzwerk befinden. Ersetzen Sie „YourGroupSid“ durch die SID, die Sie mit obigem Cmdlet ermittelt haben.

Lesen Sie unbedingt die Informationen unter Auswählen zusätzlicher Authentifizierungsanbieter in 2019.

Wichtig

Sichern Ihrer Anspruchsregeln

Festlegen einer globalen Anspruchsregel

Führen Sie das folgende PowerShell-Cmdlet aus:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

Der Befehl gibt Ihre aktuellen zusätzlichen Authentifizierungsregeln für die Vertrauensstellung der vertrauenden Seite zurück. Fügen Sie die folgenden Regeln an Ihre aktuellen Anspruchsregeln an:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Im folgenden Beispiel wird davon ausgegangen, dass Ihre aktuellen Anspruchsregeln so konfiguriert sind, dass sie zur MFA aufgefordert werden, wenn Benutzer eine Verbindung von außerhalb Ihres Netzwerks herstellen. Dieses Beispiel enthält die zusätzlichen Regeln, die Sie anfügen müssen.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Festlegen einer anwendungsspezifischen Anspruchsregel

In diesem Beispiel werden Anspruchsregeln für eine bestimmte Vertrauensstellung der vertrauenden Seite (Anwendung) geändert, und es sind die Informationen enthalten, die Sie anfügen müssen.

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == 
"http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"http://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Konfigurieren der Multi-Faktor-Authentifizierung von Microsoft Entra als Authentifizierungsanbieter in AD FS

Um die Multi-Faktor-Authentifizierung von Microsoft Entra für AD FS zu konfigurieren, müssen Sie die einzelnen AD FS-Server konfigurieren. Wenn Ihre Farm über mehrere AD FS-Server verfügt, können Sie diese remote mithilfe von Azure AD PowerShell konfigurieren.

Eine detaillierte Anleitung zu diesem Prozess finden Sie unter Konfigurieren der AD FS-Server im Artikel Konfigurieren der Multi-Faktor-Authentifizierung von Microsoft Entra als Authentifizierungsanbieter mit AD FS.

Nachdem Sie die Server konfiguriert haben, können Sie die Multi-Faktor-Authentifizierung von Microsoft Entra als zusätzliche Authentifizierungsmethode hinzufügen.

Screen shot showing the Edit authentication methods screen with Microsoft Entra multifactor authentication and Azure Multi-Factor Authentication Server selected

Vorbereiten von Microsoft Entra ID und Implementieren der Migration

In diesem Abschnitt werden die letzten Schritte vor der Migration von MFA-Benutzereinstellungen behandelt.

Festlegen von „federatedIdpMfaBehavior“ aus „enforceMfaByFederatedIdp“

Bei Verbunddomänen kann MFA durch bedingten Microsoft Entra-Zugriff oder durch den lokalen Verbundanbieter erzwungen werden. Jede Verbunddomäne verfügt über eine Microsoft Graph PowerShell-Sicherheitseinstellung namens federatedIdpMfaBehavior. Sie können federatedIdpMfaBehavior aus enforceMfaByFederatedIdp festlegen, damit Microsoft Entra ID die Multi-Faktor-Authentifizierung (MFA) akzeptiert, die vom Verbundidentitätsanbieter ausgeführt wird. Wenn der Verbundidentitätsanbieter keine MFA ausgeführt hat, leitet Microsoft Entra ID die Anforderung zur Ausführung der MFA an den Verbundidentitätsanbieter um. Weitere Informationen finden Sie unter federatedIdpMfaBehavior.

Hinweis

Bei der Einstellung federatedIdpMfaBehavior handelt es sich um eine neue Version der Eigenschaft SupportsMfa des Cmdlets New-MgDomainFederationConfiguration.

Bei Domänen, für die die Eigenschaft SupportsMfa festgelegt ist, bestimmen diese Regeln, wie federatedIdpMfaBehavior und SupportsMfa zusammenwirken:

  • Der Wechsel zwischen federatedIdpMfaBehavior und SupportsMfa wird nicht unterstützt.
  • Sobald die Eigenschaft federatedIdpMfaBehavior festgelegt wurde, ignoriert Microsoft Entra ID die Einstellung SupportsMfa.
  • Wenn die Eigenschaft federatedIdpMfaBehavior nie festgelegt wird, berücksichtigt Microsoft Entra ID die Einstellung SupportsMfa weiterhin.
  • Wenn weder federatedIdpMfaBehavior noch SupportsMfa festgelegt ist, verwendet Microsoft Entra ID standardmäßig das Verhalten acceptIfMfaDoneByFederatedIdp.

Sie können den Status von FederatedIdpMfaBehavior mithilfe von Get-MgDomainFederationConfiguration überprüfen.

Get-MgDomainFederationConfiguration –DomainID yourdomain.com

Sie können auch den Status Ihres SupportsMfa-Flags mit Get-MgDomainFederationConfiguration überprüfen:

Get-MgDomainFederationConfiguration –DomainName yourdomain.com

Im folgenden Beispiel wird gezeigt, wie FederatedIdpMfaBehavior mithilfe von Graph PowerShell auf enforceMfaByFederatedIdp festgelegt wird.

Anforderung

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

Konfigurieren von ggf. erforderlichen Richtlinien für bedingten Zugriff

Wenn Sie über den bedingten Zugriff bestimmen, wann Benutzer zur MFA aufgefordert werden, brauchen Sie Ihre Richtlinien in der Regel nicht zu ändern.

Wenn für Ihre Verbunddomänen SupportsMfa auf „False“ festgelegt ist, analysieren Sie Ihre Anspruchsregeln für die Microsoft Entra ID-Vertrauensstellung der vertrauenden Seite und erstellen Richtlinien für bedingten Zugriff, die die gleichen Sicherheitsziele unterstützen.

Nachdem Sie Richtlinien für bedingten Zugriff erstellt haben, um dieselben Steuerelemente wie AD FS zu erzwingen, können Sie Ihre Anpassungen der Anspruchsregeln für die Microsoft Entra ID-Vertrauensstellung der vertrauenden Seite sichern und entfernen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Registrieren von Benutzern für die Multi-Faktor-Authentifizierung von Microsoft Entra

In diesem Abschnitt wird erläutert, wie sich Benutzer für kombinierte Sicherheit (MFA und Self-Service-Kennwortzurücksetzung) registrieren und Benutzer ihre MFA-Einstellungen migrieren können. Microsoft Authenticator kann wie im kennwortlosen Modus verwendet werden. Sie kann auch bei beiden Registrierungsverfahren als zweiter Faktor für MFA verwendet werden.

Es wird empfohlen, dass sich Ihre Benutzer für kombinierte Sicherheitsinformationen registrieren. Dabei handelt es sich um eine zentrale Anlaufstelle zum Registrieren ihrer Authentifizierungsmethoden und Geräte für MFA und SSPR.

Microsoft stellt Kommunikationsvorlagen bereit, die Sie Ihren Benutzern zur Verfügung stellen können, um sie durch den kombinierten Registrierungsprozess zu führen. Dazu gehören Vorlagen für E-Mails, Poster, Tischaufsteller und verschiedene andere Ressourcen. Benutzer registrieren ihre Informationen unter https://aka.ms/mysecurityinfo, wodurch sie zum Bildschirm für die kombinierte Sicherheitsregistrierung weitergeleitet werden.

Es wird empfohlen, den Sicherheitsregistrierungsprozess mit bedingtem Zugriff zu schützen, sodass die Registrierung von einem vertrauenswürdigen Gerät oder Standort aus erfolgen muss. Informationen zum Nachverfolgen des Registrierungsstatus finden Sie unter Authentifizierungsmethodenaktivität für Microsoft Entra ID.

Hinweis

Wenn Benutzer ihre kombinierten Sicherheitsinformationen von einem nicht vertrauenswürdigen Standort oder Gerät registrieren müssen, kann ein befristeter Zugriffspass ausgestellt werden. Alternativ können Benutzer vorübergehend aus der Richtlinie ausgeschlossen werden.

Migrieren von MFA-Einstellungen von MFA Server

Sie können das Hilfsprogramm zur MFA-Servermigration verwenden, um registrierte MFA-Einstellungen für Benutzer aus MFA-Server mit Microsoft Entra ID zu synchronisieren. Sie können Telefonnummern, Hardwaretoken und Geräteregistrierungen wie Microsoft Authenticator-Einstellungen synchronisieren.

Hinzufügen von Benutzern zu den entsprechenden Gruppen

  • Wenn Sie neue Richtlinien für bedingten Zugriff erstellt haben, fügen Sie diesen Gruppen die entsprechenden Benutzer hinzu.

  • Wenn Sie lokale Sicherheitsgruppen für Anspruchsregeln erstellt haben, fügen Sie diesen Gruppen die entsprechenden Benutzer hinzu.

Es wird nicht empfohlen, Gruppen wiederzuverwenden, die zu Sicherheitszwecken verwendet werden. Verwenden Sie eine Sicherheitsgruppe, die Sie zum Schützen einer Gruppe von hochwertigen Apps mit einer Richtlinie für bedingten Zugriff verwenden, nur für diesen Zweck.

Überwachung

Die Registrierung der Multi-Faktor-Authentifizierung von Microsoft Entra kann mithilfe des Berichts Authentifizierungsmethoden: Nutzung und Erkenntnisse überwacht werden. Diesen Bericht finden Sie in Microsoft Entra ID. Wählen Sie Überwachung und dann Nutzung & Erkenntnisse aus.

Wählen Sie unter „Nutzung und Erkenntnisse“ die Option Authentifizierungsmethoden aus.

Ausführliche Informationen zur Registrierung der Microsoft Entra-Multi-Faktor-Authentifizierung finden Sie auf der Registerkarte „Registrierung“. Sie können per Drilldown eine Liste registrierter Benutzer anzeigen, indem Sie den Link Benutzer mit Azure MFA auswählen.

Image of Authentication methods activity screen showing user registrations to MFA

Bereinigungsschritte

Nachdem Sie die Migration zur Multi-Faktor-Authentifizierung von Microsoft Entra abgeschlossen haben und den MFA-Server außer Betrieb nehmen können, führen Sie die folgenden drei Schritte aus:

  1. Stellen Sie die Konfiguration Ihrer Anspruchsregeln für AD FS vor der Migration wieder her, und entfernen Sie den MFA-Server-Authentifizierungsanbieter.

  2. Entfernen Sie den MFA-Server als Authentifizierungsanbieter in AD FS. Dadurch wird sichergestellt, dass alle Benutzer die Multi-Faktor-Authentifizierung von Microsoft Entra verwenden, da dies die einzige zusätzliche Authentifizierungsmethode ist, die aktiviert ist.

  3. Nehmen Sie den MFA-Server außer Betrieb.

Wiederherstellen der Anspruchsregeln für AD FS und Entfernen des MFA-Server-Authentifizierungsanbieters

Führen Sie die Schritte unter „Konfigurieren von Anspruchsregeln zum Aufrufen der Multi-Faktor-Authentifizierung von Microsoft Entra“ aus, um die gesicherten Anspruchsregeln wiederherzustellen und alle AzureMFAServerAuthentication-Anspruchsregeln zu entfernen.

Entfernen Sie beispielsweise Folgendes aus den Regeln:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"http://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'

Deaktivieren von MFA-Server als Authentifizierungsanbieter in AD FS

Diese Änderung stellt sicher, dass nur die Microsoft Entra-Multi-Faktor-Authentifizierung als Authentifizierungsanbieter verwendet wird.

  1. Öffnen Sie die AD FS-Verwaltungskonsole.

  2. Klicken Sie unter Dienste mit der rechten Maustaste auf Authentifizierungsmethoden, und wählen Sie Multi-Faktor-Authentifizierungsmethoden bearbeiten aus.

  3. Deaktivieren Sie das Kontrollkästchen neben Azure Multi-Factor Authentication-Server.

Außerbetriebnahme des MFA-Servers

Führen Sie den Außerbetriebsetzungsprozess ihres Unternehmensservers aus, um die MFA-Server in Ihrer Umgebung zu entfernen.

Berücksichtigen Sie ggf. Folgendes bei der Außerbetriebnahme des MFA-Servers:

  • Überprüfen Sie die Protokolle der MFA-Server, um sicherzustellen, dass sie von keinen Benutzern oder Anwendungen verwendet werden, bevor Sie den Server entfernen.

  • Deinstallieren von Multi-Factor Authentication-Server aus der Systemsteuerung auf dem Server

  • Bereinigen Sie optional verbliebene Protokolle und Datenverzeichnisse, nachdem Sie sie zunächst gesichert haben.

  • Deinstallieren Sie ggf. das Webserver-SDK der Multi-Faktor-Authentifizierung, einschließlich aller Dateien, die sich noch in den Verzeichnissen „etpub\wwwroot\MultiFactorAuthWebServiceSdk“ und/oder „MultiFactorAuth“ befinden.

  • Bis Version 8.0 des MFA-Server kann es auch erforderlich sein, den Telefon-App-Webdienst für die Multi-Faktor-Authentifizierung zu entfernen.

Nächste Schritte