Hybridmessaginginfrastruktur mit verbesserter Sicherheit (Desktopclientzugriff)

Microsoft Entra ID
Microsoft 365
Office 365

Der Artikel zeigt, wie Sie die Multi-Faktor-Authentifizierung für Outlook-Desktopclients implementieren, die auf Microsoft Exchange zugreifen. Es gibt vier verschiedenen Architekturen, die den vier verschiedenen Möglichkeiten von Microsoft Exchange entsprechen, in dem das Benutzerpostfach vorhanden ist:

Hinweis

In den Diagrammen stehen schwarze gestrichelte Linien für Standardinteraktionen zwischen dem lokalen Active Directory, Microsoft Entra Connect, Microsoft Entra ID, Active Directory-Verbunddienste (AD FS) und Webanwendungsproxy-Komponenten. Weitere Informationen zu diesen Interaktionen finden Sie unter Erforderliche Ports und Protokolle für Hybrididentitäten.

Architektur (Exchange Online)

Diagramm, das eine Architektur für verbesserte Sicherheit in einem Szenario mit Outlook-Clientzugriff zeigt. Das Postfach des Benutzers befindet sich in Exchange Online.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

In diesem Szenario müssen Benutzer*innen eine Version des Outlook-Clients verwenden, die die moderne Authentifizierung unterstützt. Weitere Informationen finden Sie unter Funktionsweise der modernen Authentifizierung in Office 2013-, Office 2016- und Office 2019-Client-Apps. Diese Architektur ist für Outlook für Windows und Outlook für Mac geeignet.

Workflow (Exchange Online)

  1. Der oder die Benutzer*in versucht, über Outlook auf Exchange Online zuzugreifen.
  2. Exchange Online stellt die URL eines Microsoft Entra-Endpunkts zum Abrufen des Zugriffstokens bereit, um Zugriff auf das Postfach zu erhalten.
  3. Outlook stellt über diese URL eine Verbindung mit Microsoft Entra ID her.
  4. Sobald sich die Domäne im Verbund befindet, leitet Microsoft Entra ID die Anforderung an eine lokale AD FS-Instanz um.
  5. Der oder die Benutzer*in gibt Anmeldeinformationen auf einer AD FS-Anmeldeseite ein.
  6. AD FS leitet die Sitzung zurück an Microsoft Entra ID.
  7. Microsoft Entra ID wendet eine Azure-Richtlinie für bedingten Zugriff mit einer MFA-Voraussetzung für mobile Apps und Desktopclients an. Im Abschnitt Bereitstellung dieses Artikels finden Sie weitere Informationen zur Einrichtung einer solchen Richtlinie.
  8. Die Richtlinie für bedingten Zugriff ruft die Microsoft Entra-Multi-Faktor-Authentifizierung auf. Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.
  9. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab.
  10. Microsoft Entra ID stellt Zugriffs- und Aktualisierungstoken aus und gibt sie an den Client zurück.
  11. Mithilfe des Zugriffstokens stellt der Client eine Verbindung mit Exchange Online her und ruft den Inhalt ab.

Konfiguration (Exchange Online)

Sie können Zugriffsversuche auf Exchange Online über die Legacyauthentifizierung (rot gestrichelte Linie im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook verwendeten Protokolle deaktiviert. Sie müssen die folgenden Protokolle deaktivieren: Autodiscover, MAPI, OfflineAddressBook und EWS. Hier sehen Sie die entsprechende Konfiguration:

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

Das RPC-Protokoll wird für Office 365 nicht mehr unterstützt. Der letzte Parameter wirkt sich also nicht auf die Clients aus.

Hier sehen Sie einen Beispielbefehl zum Erstellen dieser Authentifizierungsrichtlinie:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

Hinweis

Standardmäßig ist nach dem Erstellen der Richtlinie auch die Legacyauthentifizierung für alle anderen Protokolle (z. B. IMAP, POP und ActiveSync) deaktiviert. Sie können dieses Verhalten ändern, indem Sie Protokolle mit einem PowerShell-Befehl wie dem folgenden aktivieren:

Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true

Nachdem Sie die Authentifizierungsrichtlinie erstellt haben, können Sie sie zunächst mit dem Befehl Set-User user01 -AuthenticationPolicy <name_of_policy> einer Pilotbenutzergruppe zuweisen. Nach Abschluss der Tests können Sie die Richtlinie auf alle Benutzer*innen erweitern. Um die Richtlinie auf Organisationsebene anzuwenden, verwenden Sie den Befehl Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Sie müssen Exchange Online PowerShell für diese Konfiguration verwenden.

Architektur (Exchange Online, AD FS)

Diagramm, das eine alternative Architektur für verbesserte Sicherheit in einem Szenario mit Outlook-Clientzugriff zeigt.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

Dieses Szenario entspricht dem vorherigen Szenario. Der einzige Unterschied besteht darin, dass ein anderer Trigger für die Multi-Faktor-Authentifizierung verwendet wird. Im vorherigen Szenario wurde eine lokale AD FS-Instanz für die Authentifizierung verwendet. Anschließend wurden die Daten zur erfolgreichen Authentifizierung an Microsoft Entra ID umgeleitet, wo die Multi-Faktor-Authentifizierung durch eine Richtlinie für bedingten Zugriff erzwungen wurde. In diesem Szenario wird die Multi-Faktor-Authentifizierung nicht über eine Richtlinie für bedingten Zugriff erzwungen, sondern es wird eine Zugriffssteuerungsrichtlinie auf AD FS-Ebene erstellt, um die Multi-Faktor-Authentifizierung dort zu erzwingen. Die restliche Architektur entspricht derjenigen aus dem vorherigen Szenario.

Hinweis

Dieses Szenario wird nur empfohlen, wenn Sie das vorherige Szenario nicht verwenden können.

In diesem Szenario müssen Benutzer*innen eine Version des Outlook-Clients verwenden, die die moderne Authentifizierung unterstützt. Weitere Informationen finden Sie unter Funktionsweise der modernen Authentifizierung in Office 2013-, Office 2016- und Office 2019-Client-Apps. Diese Architektur ist für Outlook für Windows und Outlook für Mac geeignet.

Workflow (Exchange Online, AD FS)

  1. Der oder die Benutzer*in versucht, über Outlook auf Exchange Online zuzugreifen.

  2. Exchange Online stellt die URL eines Microsoft Entra-Endpunkts zum Abrufen des Zugriffstokens bereit, um Zugriff auf das Postfach zu erhalten.

  3. Outlook stellt über diese URL eine Verbindung mit Microsoft Entra ID her.

  4. Wenn sich die Domäne im Verbund befindet, leitet Microsoft Entra ID die Anforderung an eine lokale AD FS-Instanz um.

  5. Der oder die Benutzer*in gibt Anmeldeinformationen auf einer AD FS-Anmeldeseite ein.

  6. Als Reaktion auf eine AF DS-Zugriffssteuerungsrichtlinie ruft AD FS die Microsoft Entra-Multi-Faktor-Authentifizierung auf, um die Authentifizierung abzuschließen. Hier sehen Sie ein Beispiel für eine solche AD FS-Zugriffssteuerungsrichtlinie:

    Screenshot: Beispiel für eine AD FS-Zugriffssteuerungsrichtlinie

    Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.

  7. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab.

  8. AD FS leitet die Sitzung zurück an Microsoft Entra ID.

  9. Microsoft Entra ID stellt Zugriffs- und Aktualisierungstoken aus und gibt sie an den Client zurück.

  10. Mithilfe des Zugriffstokens stellt der Client eine Verbindung mit Exchange Online her und ruft den Inhalt ab.

Konfiguration (Exchange Online, AD FS)

Hinweis

Die in Schritt 6 implementierte Zugriffssteuerungsrichtlinie wird auf die Vertrauensebene der vertrauenden Seite angewendet, sodass sie für alle Authentifizierungsanforderungen sämtlicher Office 365-Dienste gilt, die AD FS durchlaufen. Sie können AD FS-Authentifizierungsregeln verwenden, um zusätzliche Filter anzuwenden. Es wird jedoch empfohlen, eine Richtlinie für bedingten Zugriff (wie für die vorherige Architektur erläutert) anstatt einer AD FS-Zugriffssteuerungsrichtlinie für Microsoft 365-Dienste zu verwenden. Das vorherige Szenario ist gängiger und ermöglicht eine höhere Flexibilität.

Sie können Zugriffsversuche auf Exchange Online über die Legacyauthentifizierung (rot gestrichelte Linie im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook verwendeten Protokolle deaktiviert. Sie müssen die folgenden Protokolle deaktivieren: Autodiscover, MAPI, OfflineAddressBook und EWS. Hier sehen Sie die entsprechende Konfiguration:

AllowBasicAuthAutodiscover : False

AllowBasicAuthMapi : False

AllowBasicAuthOfflineAddressBook : False

AllowBasicAuthWebServices : False

AllowBasicAuthRpc : False

Das RPC-Protokoll wird für Office 365 nicht mehr unterstützt. Der letzte Parameter wirkt sich also nicht auf die Clients aus.

Hier sehen Sie einen Beispielbefehl zum Erstellen dieser Authentifizierungsrichtlinie:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false

Architektur (Exchange lokal)

Diagramm, das eine erweiterte Sicherheitsarchitektur in einem Szenario mit lokalem Outlook-Clientzugriff zeigt.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

Diese Architektur ist für Outlook für Windows und Outlook für Mac geeignet.

Workflow (Exchange lokal)

  1. Ein*e Benutzer*in mit einem Postfach in Exchange Server startet den Outlook-Client. Der Outlook-Client stellt eine Verbindung mit Exchange Server her und gibt an, dass er über moderne Authentifizierungsfunktionen verfügt.
  2. Exchange Server sendet eine Antwort an den Client, der ein Token von Microsoft Entra ID anfordert.
  3. Der Outlook-Client stellt eine Verbindung mit einer von Exchange Server bereitgestellten Microsoft Entra-URL her.
  4. Azure ermittelt, dass es sich bei der Benutzerdomäne um eine Verbunddomäne handelt und sendet über den Webanwendungsproxy Anforderungen an AD FS.
  5. Der oder die Benutzer*in gibt Anmeldeinformationen auf einer AD FS-Anmeldeseite ein.
  6. AD FS leitet die Sitzung zurück an Microsoft Entra ID.
  7. Microsoft Entra ID wendet eine Azure-Richtlinie für bedingten Zugriff mit einer MFA-Voraussetzung für mobile Apps und Desktopclients an. Im Abschnitt Bereitstellung dieses Artikels finden Sie weitere Informationen zur Einrichtung einer solchen Richtlinie.
  8. Die Richtlinie für bedingten Zugriff ruft die Microsoft Entra-Multi-Faktor-Authentifizierung auf. Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.
  9. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab.
  10. Microsoft Entra ID stellt Zugriffs- und Aktualisierungstoken aus und gibt sie an den Client zurück.
  11. Der oder die Benutzer*in gibt das Zugriffstoken in Exchange Server ein, und Exchange autorisiert den Zugriff auf das Postfach.

Konfiguration (Exchange lokal)

Sie können Zugriffsversuche auf eine lokale Exchange-Instanz über die Legacyauthentifizierung (rot gestrichelte Linie im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook verwendeten Protokolle deaktiviert. Sie müssen die folgenden Protokolle deaktivieren: Autodiscover, MAPI, OfflineAddressBook, EWS und RPC. Hier sehen Sie die entsprechende Konfiguration:

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

Das RPC-Protokoll (Remote Procedure Call, Remoteprozeduraufruf) unterstützt keine moderne Authentifizierung, also auch nicht die Microsoft Entra-Multi-Faktor-Authentifizierung. Microsoft empfiehlt das MAPI-Protokoll für Outlook für Windows-Clients.

Hier sehen Sie einen Beispielbefehl zum Erstellen dieser Authentifizierungsrichtlinie:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

Nachdem Sie die Authentifizierungsrichtlinie erstellt haben, können Sie sie zunächst mit dem Befehl Set-User user01 -AuthenticationPolicy <name_of_policy> einer Pilotbenutzergruppe zuweisen. Nach Abschluss der Tests können Sie die Richtlinie auf alle Benutzer*innen erweitern. Um die Richtlinie auf Organisationsebene anzuwenden, verwenden Sie den Befehl Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Sie müssen eine lokale Exchange PowerShell-Instanz für diese Konfiguration verwenden.

Architektur (Exchange lokal, AD FS)

Diagramm, das eine alternative erweiterte Sicherheitsarchitektur in einem Szenario mit lokalem Outlook-Clientzugriff zeigt.

Visio-Datei mit allen Diagrammen aus diesem Artikel herunterladen

Dieses Szenario ähnelt dem vorherigen Szenario. In diesem Szenario wird die Multi-Faktor-Authentifizierung jedoch durch AD FS ausgelöst. Diese Architektur ist für Outlook für Windows und Outlook für Mac geeignet.

Hinweis

Dieses Szenario wird nur empfohlen, wenn Sie das vorherige Szenario nicht verwenden können.

Workflow (Exchange lokal, AD FS)

  1. Der oder die Benutzer*in startet den Outlook-Client. Der Client stellt eine Verbindung mit Exchange Server her und gibt an, dass er über moderne Authentifizierungsfunktionen verfügt.

  2. Exchange Server sendet eine Antwort an den Client, der ein Token von Microsoft Entra ID anfordert. Exchange Server stellt dem Client eine URL zu Microsoft Entra ID bereit.

  3. Der Client verwendet die URL für den Zugriff auf Microsoft Entra ID.

  4. In diesem Szenario handelt es sich um eine Verbunddomäne. Microsoft Entra ID leitet den Client über den Webanwendungsproxy an AD FS um.

  5. Der oder die Benutzer*in gibt Anmeldeinformationen auf einer AD FS-Anmeldeseite ein.

  6. AD FS löst die Multi-Faktor-Authentifizierung aus. Hier sehen Sie ein Beispiel für eine solche AD FS-Zugriffssteuerungsrichtlinie:

    Screenshot: AD FS-Zugriffssteuerungsrichtlinie

    Die Benutzer*innen werden zur Multi-Faktor-Authentifizierung aufgefordert.

  7. Die Benutzer*innen schließen die Multi-Faktor-Authentifizierung ab.

  8. AD FS leitet die Sitzung zurück an Microsoft Entra ID.

  9. Microsoft Entra ID stellt Zugriffs- und Aktualisierungstoken für die Benutzer*innen aus.

  10. Der Client stellt das Zugriffstoken für den lokalen Exchange-Server bereit. Exchange autorisiert den Zugriff auf das Postfach des Benutzers oder der Benutzerin.

Konfiguration (Exchange lokal, AD FS)

Hinweis

Die in Schritt 6 implementierte Zugriffssteuerungsrichtlinie wird auf die Vertrauensebene der vertrauenden Seite angewendet, sodass sie für alle Authentifizierungsanforderungen sämtlicher Office 365-Dienste gilt, die AD FS durchlaufen. Sie können AD FS-Authentifizierungsregeln verwenden, um zusätzliche Filter anzuwenden. Es wird jedoch empfohlen, eine Richtlinie für bedingten Zugriff (wie für die vorherige Architektur erläutert) anstatt einer AD FS-Zugriffssteuerungsrichtlinie für Microsoft 365-Dienste zu verwenden. Das vorherige Szenario ist gängiger und ermöglicht eine höhere Flexibilität.

Sie können Zugriffsversuche auf eine lokale Exchange-Instanz über die Legacyauthentifizierung (rot gestrichelte Linie im Diagramm) blockieren, indem Sie eine Authentifizierungsrichtlinie erstellen, die die Legacyauthentifizierung für die von Outlook verwendeten Protokolle deaktiviert. Sie müssen die folgenden Protokolle deaktivieren: Autodiscover, MAPI, OfflineAddressBook, EWS und RPC. Hier sehen Sie die entsprechende Konfiguration:

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthMapi : True

BlockLegacyAuthOfflineAddressBook : True

BlockLegacyAuthRpc : True

BlockLegacyAuthWebServices : True

Das RPC-Protokoll (Remote Procedure Call, Remoteprozeduraufruf) unterstützt keine moderne Authentifizierung, also auch nicht die Microsoft Entra-Multi-Faktor-Authentifizierung. Microsoft empfiehlt das MAPI-Protokoll für Outlook für Windows-Clients.

Hier sehen Sie einen Beispielbefehl zum Erstellen dieser Authentifizierungsrichtlinie:

New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc

Nachdem Sie die Authentifizierungsrichtlinie erstellt haben, können Sie sie zunächst mit dem Befehl Set-User user01 -AuthenticationPolicy <name_of_policy> einer Pilotbenutzergruppe zuweisen. Nach Abschluss der Tests können Sie die Richtlinie auf alle Benutzer*innen erweitern. Um die Richtlinie auf Organisationsebene anzuwenden, verwenden Sie den Befehl Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Sie müssen eine lokale Exchange PowerShell-Instanz für diese Konfiguration verwenden.

Komponenten

  • Microsoft Entra ID. Microsoft Entra ID ist ein cloudbasierter Identitäts- und Zugriffsverwaltungsdienst von Microsoft. Er ermöglicht eine moderne Authentifizierung, die im Wesentlichen auf EvoSTS basiert (einem von Microsoft Entra ID verwendeten Sicherheitstokendienst). Er wird als Authentifizierungsserver für lokale Exchange Server-Instanzen verwendet.
  • Microsoft Entra-Multi-Faktor-Authentifizierung. Die Multi-Faktor-Authentifizierung ist ein Prozess, bei dem Benutzer*innen während des Anmeldevorgangs zur Durchführung eines weiteren Identifizierungsverfahrens aufgefordert werden, z. B. per Eingabe eines Codes auf dem Smartphone oder per Fingerabdruckscan.
  • Bedingter Microsoft Entra-Zugriff. Der bedingte Zugriff ist ein Feature, mit dem Microsoft Entra ID Organisationsrichtlinien wie die Multi-Faktor-Authentifizierung erzwingt.
  • AD FS: AD FS ermöglicht die Identitäts- und Zugriffsverwaltung im Verbund, indem digitale Identitäten und Berechtigungen auch jenseits von Sicherheits- und Unternehmensgrenzen mit verbesserter Sicherheit geteilt werden. In diesen Architekturen wird der Dienst eingesetzt, um die Anmeldung von Benutzer*innen mit Verbundidentitäten zu vereinfachen.
  • Webanwendungsproxy: Der Webanwendungsproxy authentifiziert den Zugriff auf Webanwendungen vorab mit AD FS. Sie fungiert auch als AD FS-Proxy.
  • Microsoft Intune. Intune ist unsere cloudbasierte einheitliche Endpunktverwaltungslösung, die Endpunkte für Windows-, Android-, Mac-, iOS- und Linux-Betriebssysteme verwaltet.
  • Exchange Server: Exchange Server hostet lokale Benutzerpostfächer. In diesen Architekturen werden Token verwendet, die Benutzer*innen von Microsoft Entra ID ausgestellt werden, um den Zugriff auf Postfächer zu autorisieren.
  • Active Directory-Dienste: Active Directory-Dienste speichern Informationen zu Mitgliedern einer Domäne, einschließlich Geräten und Benutzer*innen. In diesen Architekturen gehören Benutzerkonten zu Active Directory-Diensten und werden mit Microsoft Entra ID synchronisiert.
  • Outlook for Business: Outlook ist eine Clientanwendung, die die moderne Authentifizierung unterstützt.

Szenariodetails

Enterprise Messaging Infrastructure (EMI) ist ein wichtiger Dienst für Organisationen. Der Wechsel von älteren, weniger sicheren Authentifizierungs- und Autorisierungsmethoden zu einer modernen Authentifizierung ist ein wichtiger Schritt in einer Welt, in der Remotearbeit üblich ist. Die Implementierung von MFA-Voraussetzungen für den Zugriff auf Messagingdienste ist eine der effektivsten Methoden, um dieses Ziel zu erreichen.

In diesem Artikel werden vier Architekturen beschrieben, mit denen Sie die Sicherheit beim Zugriff auf Outlook über einen Desktopclient mithilfe der Microsoft Entra-Multi-Faktor-Authentifizierung erhöhen können.

Dies sind vier Architekturen gemäß vier verschiedenen Möglichkeiten für Microsoft Exchange:

Alle vier Architekturen sind sowohl für Outlook für Windows als auch für Outlook für Mac geeignet.

Informationen zum Anwenden der Multi-Faktor-Authentifizierung in anderen Hybridmessagingszenarios finden Sie in den folgenden Artikeln:

Andere Protokolle wie IMAP oder POP werden in diesem Artikel nicht behandelt. In der Regel werden diese Protokolle in solchen Szenarios nicht verwendet.

Allgemeine Hinweise

  • Diese Architekturen verwenden das Verbundidentitätsmodell von Microsoft Entra. Die Logik und der Ablauf für die Kennwort-Hashsynchronisierung und die Passthrough-Authentifizierung sind identisch. Der einzige Unterschied besteht darin, dass Microsoft Entra ID die Authentifizierungsanforderung nicht an lokale Active Directory-Verbunddienste (AD FS) umleitet.
  • Mit lokale Exchange-Instanz ist Exchange 2019 mit den neuesten Updates und der Rolle „Postfach“ gemeint.
  • In einer realen Umgebung ist nicht nur ein Server vorhanden. Sie besitzen eine Reihe von Exchange-Servern mit Lastenausgleich, um Hochverfügbarkeit zu gewährleisten. Die hier beschriebenen Szenarios eignen sich für diese Konfiguration.

Mögliche Anwendungsfälle

Diese Architektur ist für die folgenden Szenarios relevant:

  • Verbesserung der EMI-Sicherheit
  • Einführung einer Zero-Trust-Sicherheitsstrategie
  • Anwendung hoher Sicherheitsstandards für Ihren lokalen Messagingdienst während des Übergangs zu Exchange Online oder bei parallelem Betrieb mit Exchange Online
  • Erzwingung von strengen Sicherheits- oder Complianceanforderungen in geschlossenen Organisationen oder Organisationen mit höchsten Sicherheitsvorschriften wie in der Finanzbranche

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Verfügbarkeit

Die allgemeine Verfügbarkeit hängt von der Verfügbarkeit der beteiligten Komponenten ab. Informationen zur Verfügbarkeit finden Sie in den folgenden Artikeln:

Die Verfügbarkeit lokaler Lösungskomponenten hängt vom implementierten Design, der Hardwareverfügbarkeit und den internen Betriebs- und Wartungsroutinen ab. Informationen zur Verfügbarkeit einiger dieser Komponenten finden Sie in den folgenden Artikeln:

Damit Sie die moderne Hybridauthentifizierung verwenden können, müssen alle Clients in Ihrem Netzwerk auf Microsoft Entra ID zugreifen können. Außerdem müssen Sie die Firewallports und geöffneten IP-Adressbereiche für Office 365 permanent verwalten.

Weitere Informationen zu Protokoll- und Portanforderungen für Exchange Server finden Sie im Abschnitt „Anforderungen für Exchange-Clients und -Protokolle“ unter Moderne Hybridauthentifizierung: Übersicht und Voraussetzungen für die Verwendung mit lokalen Skype for Business- und Exchange-Servern.

Die IP-Adressbereiche und Ports für Office 365 finden Sie unter Office 365-URLs und -IP-Adressbereiche.

Weitere Informationen zur modernen Hybridauthentifizierung und mobilen Geräten finden Sie im Abschnitt zu AutoDetect-Endpunkten unter Andere nicht im IP-Adressbereich und URL-Webdienst für Office 365 enthaltene Endpunkte.

Resilienz

Weitere Informationen zur Resilienz der Komponenten in dieser Architektur finden Sie in den folgenden Artikeln:

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Weitere Informationen zu Sicherheit und zur modernen Hybridauthentifizierung finden Sie unter Ausführliche Erläuterung der Funktionsweise der Hybridauthentifizierung.

Geschlossene Organisationen, die den üblichen starken Perimeterschutz anwenden, müssen einige Sicherheitsbedenken zu klassischen Exchange-Hybridkonfigurationen beachten. Die moderne Exchange-Hybridkonfiguration unterstützt die moderne Hybridauthentifizierung nicht.

Informationen zu Microsoft Entra ID finden Sie unter Leitfaden für Microsoft Entra-SecOps.

Weitere Informationen zu Szenarios mit AD FS-Sicherheit finden Sie in den folgenden Artikeln:

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kosten für Ihre Implementierung hängen von Ihren Microsoft Entra ID- und Microsoft 365-Lizenzkosten ab. Die Gesamtkosten umfassen auch die Kosten für Software und Hardware für lokale Komponenten, den IT-Betrieb, Schulungen und Projektimplementierung.

Für diese Lösungen ist mindestens Microsoft Entra ID P1 erforderlich. Informationen zu den Preisen finden Sie unter Microsoft Entra-Preise.

Weitere Informationen zu den Preisen für AD FS und den Webanwendungsproxy finden Sie unter Preise und Lizenzierungsoptionen für Windows Server 2022.

Weitere Preisinformationen finden Sie in den folgenden Ressourcen:

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen Ihrer Benutzer*innen auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Die Workloadleistung hängt von der Leistung der beteiligten Komponenten und der Netzwerkleistung ab. Weitere Informationen finden Sie unter Leistungsoptimierung für Office 365 mithilfe von Baselines und Leistungsverlauf.

Weitere Informationen zu lokalen Faktoren, die die Leistung in AD FS-Szenarios beeinflussen, finden Sie in den folgenden Artikeln:

Weitere Informationen zur Skalierbarkeit von AD FS finden Sie unter Planen der AD FS-Serverkapazität.

Weitere Informationen zur Skalierbarkeit von lokalen Exchange Server-Instanzen finden Sie unter Bevorzugte Architektur für Exchange 2019.

Bereitstellen dieses Szenarios

Die allgemeinen Schritte sind folgende:

  1. Schützen Sie den Zugriff auf den Outlook-Desktopclient durch eine Exchange-Hybridkonfiguration und die Aktivierung der modernen Hybridauthentifizierung.
  2. Blockieren Sie alle Authentifizierungsversuche über Legacymethoden auf der Microsoft Entra ID-Ebene. Blockieren Sie Authentifizierungsversuche über Legacymethoden auf Messagingdienstebene, indem Sie Authentifizierungsrichtlinien anwenden.

Einrichten einer Richtlinie für bedingten Zugriff

Gehen Sie wie im Folgenden beschrieben vor, um wie für einige Architekturen in diesem Artikel beschrieben eine Microsoft Entra-Richtlinie für bedingten Zugriff einzurichten, die die Multi-Faktor-Authentifizierung erzwingt:

  1. Wählen Sie im Fenster Client-Apps die Option Mobile Apps und Desktopclients aus:

    Screenshot: Fenster „Client-Apps“

  2. Wenden Sie im Fenster Gewähren die Anforderung „Multi-Faktor-Authentifizierung“ an:

    Screenshot: Fenster „Gewähren“

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte