Konfigurieren des erweiterten Windows-Schutzes in Exchange Server

Übersicht

Windows Extended Protection verbessert die vorhandene Authentifizierung in Windows Server und entschärft Authentifizierungsrelay- oder Man-in-the-Middle-Angriffe (MitM). Diese Entschärfung wird mithilfe von Sicherheitsinformationen erreicht, die über Kanalbindungsinformationen implementiert werden, die über eine Channel Binding Token (CBT) angegeben werden, die hauptsächlich für TLS-Verbindungen verwendet werden.

Der erweiterte Schutz ist bei der Installation von Exchange Server 2019 CU14 (oder höher) standardmäßig aktiviert. Weitere Informationen finden Sie unter Veröffentlicht: Kumulatives Update 2024 H1 für Exchange Server.

In älteren Versionen von Exchange Server (z. B. Exchange Server 2016) kann erweiterter Schutz mithilfe desExchangeExtendedProtectionManagement.ps1-Skripts auf einigen oder allen Exchange-Servern aktiviert werden.

In dieser Dokumentation verwendete Terminologie

Virtuelles Verzeichnis oder vDir

Wird von Exchange Server verwendet, um den Zugriff auf Webanwendungen wie Exchange ActiveSync, Outlook on the Webund den AutoDiscover Dienst zuzulassen. Ein Administrator kann mehrere Einstellungen für virtuelle Verzeichnisse konfigurieren, einschließlich Authentifizierungs-, Sicherheits- und Berichterstellungseinstellungen. Erweiterter Schutz ist eine solche Authentifizierungseinstellung.

Einstellung für erweiterten Schutz

Steuert das Verhalten für die Überprüfung von Channel Binding Tokens oder CBT. Mögliche Werte für diese Einstellung sind in der folgenden Tabelle aufgeführt:

Einstellung für erweiterten Schutz	Beschreibung
Keine	Gibt an, dass IIS keine CBT-Überprüfung durchführt.
Zulassen	Gibt an, dass die CBT-Überprüfung aktiviert, aber nicht erforderlich ist. Diese Einstellung ermöglicht eine sichere Kommunikation mit Clients, die erweiterten Schutz unterstützen, und unterstützt weiterhin Clients, die den erweiterten Schutz nicht verwenden können.
Erforderlich	Dieser Wert gibt an, dass eine CBT-Überprüfung erforderlich ist. Diese Einstellung blockiert Clients, die den erweiterten Schutz nicht unterstützen.

SSL-Flags

Die Konfiguration von SSL-Einstellungen ist erforderlich, um sicherzustellen, dass Clients mit Clientzertifikaten auf bestimmte Weise eine Verbindung mit virtuellen IIS-Verzeichnissen herstellen. Zum Aktivieren des erweiterten Schutzes sind SSL die erforderlichen SSL-Flags und SSL128.

SSL-Abladung

Beendet die Verbindung auf einem Gerät zwischen dem Client und dem Exchange Server und verwendet dann eine nicht verschlüsselte Verbindung, um eine Verbindung mit dem Exchange Server herzustellen.

SSL-Bridging

Beschreibt einen Prozess, bei dem ein Gerät, das sich am Rand eines Netzwerks befindet, SSL-Datenverkehr entschlüsselt und dann erneut verschlüsselt, bevor er an den Webserver gesendet wird.

Moderner Hybrid- oder Hybrid-Agent

Dies ist der Name einer Methode zum Konfigurieren von Exchange-Hybriden, die einige konfigurationsanforderungen für klassische Hybride (z. B. eingehende Netzwerkverbindungen über Ihre Firewall) entfernt, um Exchange-Hybridfeatures zu aktivieren. Weitere Informationen zu diesem Feature finden Sie hier.

Öffentliche Ordner

Sind für den gemeinsamen Zugriff konzipiert und erleichtern das Durchsuchen von Inhalten in einer tiefen Hierarchie. Weitere Informationen zu öffentlichen Ordnern finden Sie hier.

Voraussetzungen für die Aktivierung des erweiterten Schutzes auf Exchange Server

Wichtig

Es wird empfohlen, das Exchange Server-Integritätsprüfungsskript auszuführen, um zu überprüfen, ob alle Voraussetzungen auf dem Exchange-Server erfüllt sind, auf dem der erweiterte Schutz aktiviert werden soll.

Exchange Server-Versionen, die erweiterten Schutz unterstützen

Erweiterter Schutz wird ab Exchange Server 2013, 2016 und 2019 ab den Versionen des Exchange Server Sicherheitsupdates (SU) vom August 2022 unterstützt.

Wenn auf Ihrem organization Exchange Server 2016 oder Exchange Server 2019 installiert ist, muss entweder das kumulative Exchange-Updates vom September 2021 oder das kumulative Update 2022 H1 ausgeführt werden. Sie müssen mindestens das Sicherheitsupdate vom August 2022 oder höher installiert haben, bevor Sie mit der Konfiguration des erweiterten Schutzes fortfahren können.

Wenn auf Ihrem organization Exchange Server 2013 installiert ist, muss Exchange Server mit installiertem Sicherheitsupdate vom August 2022 oder höher auf CU23 installiert sein.

Warnung

Exchange Server 2013 hat das Ende des Supports am 11. April 2023 erreicht.

Konfigurationsanforderungen für Outlook Anywhere

Die SSL-Abladung für Outlook Anywhere ist standardmäßig aktiviert und muss deaktiviert werden , bevor der erweiterte Schutz aktiviert wird. Führen Sie die in Beispiel 3 beschriebenen Schritte aus.

Wichtig

Exchange Server Installationsprogramm für CU14 (oder höher) von 2019 deaktiviert die SSL-Abladung für Outlook Anywhere automatisch. Dies ist Teil des standardmäßig aktivierten erweiterten Schutzes.

NTLM-Versionsanforderungen

NTLMv1 ist schwach und bietet keinen Schutz vor Man-in-the-Middle-Angriffen (MitM). Es sollte als anfällig betrachtet werden und nicht mehr verwendet werden.

NTLMv1 kann nicht zusammen mit erweitertem Schutz verwendet werden. Wenn Sie die Verwendung NTLMv1 eines Clients anstelle von NTLMv2 erzwingen und auf Ihren Exchange-Servern den erweiterten Schutz aktiviert haben, führt diese Konfiguration zu Kennwortaufforderungen auf der Clientseite, ohne dass eine Möglichkeit besteht, sich erfolgreich beim Exchange-Server zu authentifizieren.

Hinweis

Um die Sicherheit zu erhöhen, empfiehlt es sich, diese Einstellung unabhängig davon, ob Probleme auftreten, zu überprüfen und zu konfigurieren.

Wenn auf Ihren Clients nach der Aktivierung des erweiterten Schutzes Kennwortaufforderungen angezeigt werden, sollten Sie den folgenden Registrierungsschlüssel und wert auf Ihrem Client und auf der Exchange Server Seite überprüfen:

Registrierungsschlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Registrierungswert: LmCompatibilityLevel

Es wird empfohlen, ihn auf den Wert festzulegen, der 5ist Send NTLMv2 response only. Refuse LM & NTLM. Es muss mindestens auf einen Wert festgelegt werden, der ist 3Send NTLMv2 response only.

Wenn Sie den Wert löschen, erzwingt das Betriebssystem den Systemstandard. Unter Windows Server 2008 R2 und höher wird es so behandelt, als wäre er auf 3festgelegt.

Wenn Sie die Einstellung zentral verwalten möchten, können Sie dazu Gruppenrichtlinie:

Richtlinienspeicherort: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Weitere Informationen: Netzwerksicherheit: LAN Manager-Authentifizierungsebene

TLS-Anforderungen

Vor dem Aktivieren des erweiterten Schutzes müssen Sie sicherstellen, dass alle TLS-Konfigurationen auf allen Exchange-Servern konsistent sind. Wenn beispielsweise einer der Server verwendetTLS 1.2, müssen Sie sicherstellen, dass alle Server im organization mit TLS 1.2konfiguriert sind. Jede Unterschiedliche Verwendung der TLS-Version zwischen Servern kann dazu führen, dass Client- oder Server-zu-Server-Verbindungen fehlschlagen.

Zusätzlich zu dieser Anforderung muss der Wert des SchUseStrongCrypto Registrierungswerts auf allen Exchange-Servern innerhalb des organization auf den Wert 1 festgelegt werden.

Wenn dieser Wert nicht explizit auf 1festgelegt ist, kann der Standardwert dieses Schlüssels als 0 oder 1 abhängig von der .NET-Version interpretiert werden, die von den Exchange Server Binärdateien verwendet wird, und es besteht die Möglichkeit, dass Bei der Kommunikation zwischen Server und Server Verbindungsprobleme auftreten. Dies kann der Fall sein, insbesondere wenn verschiedene Versionen von Exchange Server (z. B. Exchange Server 2016 und Exchange Server 2019) verwendet werden.

Gleiches gilt für den SystemDefaultTlsVersions Registrierungswert, der auch explizit auf den Wert festgelegt 1werden muss.

Wenn diese Registrierungswerte nicht wie erwartet konfiguriert sind, kann diese Fehlkonfiguration zu einem TLS-Konflikt zwischen Server-zu-Server- oder Client-zu-Server-Kommunikation führen, was zu Konnektivitätsproblemen führen kann.

Informationen zum Konfigurieren der erforderlichen TLS-Einstellungen auf Ihren Exchange-Servern finden Sie in diesem Exchange Server Leitfaden zu bewährten Methoden für die TLS-Konfiguration.

Kompatibilität von Drittanbietersoftware

Stellen Sie sicher, dass Sie alle Produkte von Drittanbietern testen, die in Ihrer Exchange Server-Umgebung ausgeführt werden, um sicherzustellen, dass sie ordnungsgemäß funktionieren, wenn erweiterter Schutz aktiviert ist.

Wir haben beispielsweise Antivirenlösungen gesehen, die Verbindungen über einen lokalen Proxyserver sendeten, um den Clientcomputer zu schützen. Ein solches Szenario würde die Kommunikation mit dem Exchange-Server verhindern und müsste deaktiviert werden, da es als Man-in-the-Middle-Verbindung (MitM) betrachtet wird, die durch den erweiterten Schutz blockiert wird.

Szenarien, die sich auf die Clientkonnektivität auswirken können, wenn der erweiterte Schutz aktiviert wurde

SSL-Abladungsszenarien

Der erweiterte Schutz wird in Umgebungen, die SSL-Auslagerung verwenden, nicht unterstützt . Die SSL-Beendigung während der SSL-Abladung führt dazu, dass der erweiterte Schutz fehlschlägt. Um den erweiterten Schutz in Ihrer Exchange-Umgebung zu aktivieren, dürfen Sie keine SSL-Auslagerung mit Ihren Lastenausgleichsmodulen verwenden.

SSL-Überbrückungsszenarien

Erweiterter Schutz wird in Umgebungen unterstützt , die SSL-Bridging unter bestimmten Bedingungen verwenden. Um den erweiterten Schutz in Ihrer Exchange-Umgebung mithilfe von SSL Bridging zu aktivieren, müssen Sie dasselbe SSL-Zertifikat für Exchange und Ihre Lastenausgleichsmodule verwenden. Die Verwendung verschiedener Zertifikate führt dazu, dass die Überprüfung des erweiterten Schutzkanalbindungstokens fehlschlägt und clients daher keine Verbindung mit dem Exchange-Server herstellen können.

Szenarien für erweiterten Schutz und öffentliche Ordner

Im folgenden Abschnitt werden Szenarien mit öffentlichen Ordnern behandelt, die zu Fehlern führen können, wenn erweiterter Schutz aktiviert ist.

Erweiterter Schutz kann auf Exchange Server 2013-Servern mit öffentlichen Ordnern in einer Koexistenzumgebung nicht aktiviert werden

Um den erweiterten Schutz am Exchange Server 2013 zu aktivieren, stellen Sie sicher, dass Sie über keine öffentlichen Ordner verfügen, die unter Exchange Server 2013 gehostet werden. Wenn Sie Exchange Server 2013 mit Exchange Server 2016 oder Exchange Server 2019 koexistieren, müssen Sie Ihre öffentlichen Ordner zum Exchange Server 2016 oder Exchange Server 2019 migrieren, bevor Sie den erweiterten Schutz aktivieren. Nachdem der erweiterte Schutz aktiviert wurde und am Exchange Server 2013 öffentliche Ordner vorhanden sind, werden sie endbenutzern nicht mehr angezeigt!

Warnung

Exchange Server 2013 hat das Ende des Supports am 11. April 2023 erreicht.

Der erweiterte Schutz kann nicht auf Exchange Server 2016 CU22 oder Exchange Server 2019 CU11 oder älter aktiviert werden, die eine Öffentliche Ordner-Hierarchie hostet

Wenn Sie über eine Umgebung mit Exchange Server 2016 CU22 oder Exchange Server 2019 CU11 oder älter verfügen und öffentliche Ordner verwenden, müssen Sie die Version des Servers bestätigen, auf dem die Öffentliche Ordner-Hierarchie gehostet wird, bevor Sie den erweiterten Schutz aktivieren!

Stellen Sie sicher, dass der Server, der die Öffentliche Ordner-Hierarchie hostet, auf Exchange Server 2016 CU23 oder Exchange Server 2019 CU12 (oder höher) aktualisiert wird, wobei die neueste Security Updates installiert ist. Verschieben Sie die Hierarchie öffentlicher Ordner in eine Exchange Server, die eine erforderliche Version ausführt, wenn Sie den Exchange-Server nicht auf eine unterstützte Version aktualisieren können.

Die folgende Tabelle kann verwendet werden, um folgendes zu verdeutlichen:

Exchange-Version	CU installiert	SU installiert	Hosten von PF-Postfächern	Wird EP unterstützt?
Exchange 2013	CU23	August 2022 (oder höher)	Nein	Ja
Exchange 2016	CU22	August 2022 (oder höher)	Keine Hierarchiepostfächer	Ja
Exchange 2016	CU23 (2022 H1) oder höher	August 2022 (oder höher)	Any	Ja
Exchange 2019	CU11	August 2022 (oder höher)	Keine Hierarchiepostfächer	Ja
Exchange 2019	CU12 (2022 H1) oder höher	August 2022 (oder höher)	Beliebig	Ja
Jede andere Version	Jedes andere CU	Alle anderen SU	Beliebig	Nein

Erweiterte Schutz- und moderne Hybridkonfiguration

Im folgenden Abschnitt werden Exchange Server Szenarien mit modernen Hybriden behandelt, die zu Fehlern führen können, wenn erweiterter Schutz aktiviert ist.

Der erweiterte Schutz kann auf Exchange-Servern, die mit dem Hybrid-Agent veröffentlicht werden, nicht vollständig konfiguriert werden.

In einer modernen Hybridkonfiguration werden Exchange-Server über einen Hybrid-Agent veröffentlicht, der die Exchange Online Aufrufe an den Exchange-Server weitergibt.

Das Aktivieren des erweiterten Schutzes auf Exchange-Servern, die über den Hybrid-Agent veröffentlicht werden, kann zu einer Unterbrechung von Hybridfeatures wie Postfachverschiebungen und Frei/Gebucht-Anrufen führen, wenn sie nicht ordnungsgemäß durchgeführt werden. Daher ist es wichtig, alle Exchange-Server zu identifizieren, die mit Hilfe eines Hybrid-Agents veröffentlicht werden, und den erweiterten Schutz nicht für das virtuelle EWS-Verzeichnis Front-End darauf zu aktivieren.

Identifizieren von Exchange-Servern, die mithilfe des Hybrid-Agents veröffentlicht werden

Falls Sie nicht über eine Liste von Servern verfügen, die über den Hybrid-Agent veröffentlicht wurden, können Sie die folgenden Schritte ausführen, um diese zu identifizieren. Diese Schritte sind nicht erforderlich, wenn Sie eine klassische Exchange Server Hybridbereitstellung ausführen.

1. Melden Sie sich bei einem Computer an, auf dem der Hybrid-Agent installiert ist, und öffnen Sie das PowerShell-Modul des Hybrid-Agents. Führen Sie aus Get-HybridApplication , um die TargetUri vom Hybrid-Agent verwendete zu identifizieren.
2. Mit TargetUri dem Parameter erhalten Sie den Fqdn des Exchange-Servers, der für die Verwendung durch den Hybrid-Agent konfiguriert ist.
   • Leiten Sie die Exchange-Serveridentität mithilfe des Fqdn ab, und notieren Sie sich den Exchange-Servernamen.
   • Wenn Sie eine Load Balancer URL in TargetUriverwenden, müssen Sie alle Exchange-Server identifizieren, auf denen die Client Access Rolle installiert ist und die hinter der Load Balancer-URL erreichbar sind.

Wichtig

Der erweiterte Schutz darf nicht für das virtuelle EWS-Verzeichnis Front-End auf Exchange-Servern aktiviert werden, die über einen Hybrid-Agent veröffentlicht werden.

Wir empfehlen die folgenden Schritte zum Schutz von Exchange-Servern, die über den Hybrid-Agent veröffentlicht wurden:

Hinweis

Im folgenden Szenario wird der Hybrid-Agent auf einem Server installiert, auf dem NICHT Exchange Server ausgeführt wird. Darüber hinaus befindet sich dieser Server in einem anderen Netzwerksegment als die Exchange-Produktionsserver.

1. Bei Exchange-Servern, die über den Hybrid-Agent veröffentlicht werden, sollten eingehende Verbindungen durch eine Firewall eingeschränkt werden, sodass nur Verbindungen von dem Computer zugelassen werden, auf dem der Hybrid-Agent installiert ist. Dies wirkt sich nicht auf die ausgehende Kommunikation zwischen Exchange-Servern und Exchange Online aus.
2. Auf den Exchange-Servern, die über den Hybrid-Agent veröffentlicht wurden, sollten keine Postfächer gehostet werden. Vorhandene Postfächer sollten zu anderen Postfachservern migriert werden.

Aktivieren des erweiterten Schutzes

Der erweiterte Schutz wird während Exchange Server CU14-Setup (oder höher) von Exchange Server 2019 automatisch aktiviert. In älteren Versionen von Exchange Server, die erweiterten Schutz unterstützen, kann es über ein von Microsoft bereitgestelltes Skript (empfohlen) oder manuell über IIS-Manager aktiviert werden.

Zum ordnungsgemäßen Konfigurieren des erweiterten Schutzes muss jedes virtuelle Verzeichnis auf allen Exchange-Servern im organization (ausgenommen Edge-Transport-Server) auf den vorgeschriebenen Wert und Extended ProtectionsslFlagsfestgelegt werden.

In der folgenden Tabelle sind die Einstellungen zusammengefasst, die für jedes virtuelle Verzeichnis in den unterstützten Versionen von Microsoft Exchange erforderlich sind.

IIS-Website	Virtuelles Verzeichnis	Empfohlener erweiterter Schutz	Empfohlene sslFlags
Default Website	API	Required	Ssl,Ssl128
Default Website	AutoDiscover	Off	Ssl,Ssl128
Default Website	ECP	Required	Ssl,Ssl128
Default Website	EWS	Accept (UI) / Allow (Skript)	Ssl,Ssl128
Default Website	MAPI	Required	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync	Accept (UI) / Allow (Skript)	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync/Proxy	Accept (UI) / Allow (Skript)	Ssl,Ssl128
Default Website	OAB	Accept (UI) / Allow (Skript)	Ssl,Ssl128
Default Website	OWA	Required	Ssl,Ssl128
Default Website	PowerShell	Off	SslNegotiateCert
Default Website	RPC	Required	Ssl,Ssl128
Exchange Backend	API	Required	Ssl,Ssl128
Exchange Backend	AutoDiscover	Off	Ssl,Ssl128
Exchange Backend	ECP	Required	Ssl,Ssl128
Exchange Backend	EWS	Required	Ssl,Ssl128
Exchange Backend	Microsoft-Server-ActiveSync	Required	Ssl,Ssl128
Exchange Backend	Microsoft-Server-ActiveSync/Proxy	Required	Ssl,Ssl128
Exchange Backend	OAB	Required	Ssl,Ssl128
Exchange Backend	OWA	Required	Ssl,Ssl128
Exchange Backend	PowerShell	Required	Ssl,SslNegotiateCert,Ssl128
Exchange Backend	RPC	Required	Ssl,Ssl128
Exchange Backend	PushNotifications	Required	Ssl,Ssl128
Exchange Backend	RPCWithCert	Required	Ssl,Ssl128
Exchange Backend	MAPI/emsmdb	Required	Ssl,Ssl128
Exchange Backend	MAPI/nspi	Required	Ssl,Ssl128

Hinweis

Nach dem ersten Release haben wir aktualisiert Default Website/OAB , um Accept/Allow anstelle von Required und Default Website/PowerShell zu OffRequiredsein. Die Änderung an Default Website/OAB ist darauf zurückzuführen, dass Outlook für Mac Clients das OAB nicht mehr mit der Required Einstellung herunterladen können. Die Änderung an Default Website/PowerShell liegt daran, dass die Exchange Server Standardkonfiguration keine Verbindungen mit PowerShell Front-End virtuellen Verzeichnis über NTLM zulässt und daher der erweiterte Schutz nicht anwendbar ist.

Das Vornehmen von Änderungen am Default Website/PowerShell virtuellen Verzeichnis wird nur unterstützt, wenn dies ausdrücklich vom Microsoft-Kundendienst und -Support (CSS) empfohlen wird.

Aktivieren des erweiterten Schutzes mit Exchange Server 2019 CU14-Installationsprogramm (oder höher)

Mit Exchange Server 2019 CU14 und höher aktiviert das Installationsprogramm für Exchange Server 2019 kumulatives Update (CU) automatisch erweiterten Schutz auf dem Postfachserver, auf dem das Setup ausgeführt wird. Dies geschieht bei jeder neuen Installation oder beim Upgrade einer vorhandenen Exchange Server Installation auf die neueste Version.

Es gibt zwei neue Parameter, die im unbeaufsichtigten Setupmodus verwendet werden können, um das standardmäßig aktivierte Verhalten des erweiterten Schutzes zu steuern.

Die Parameter können verwendet werden, um die automatische Aktivierung des erweiterten Schutzes (/DoNotEnableEP) zu überspringen oder den erweiterten Schutz im Front-End virtuellen EWS-Verzeichnis (/DoNotEnableEP_FEEWS) nicht zu aktivieren.

Warnung

Das Deaktivieren des erweiterten Schutzes macht Ihren Server anfällig für bekannte Exchange-Sicherheitsrisiken und schwächt den Schutz vor unbekannten Bedrohungen. Es wird empfohlen, dieses Feature aktiviert zu lassen.

Konfigurationsszenarien für das CU-Installationsprogramm für erweiterten Schutz

In diesem Abschnitt finden Sie die gängigsten Szenarien zum Konfigurieren des erweiterten Schutzes auf Exchange Server mithilfe des installationsprogramms für Exchange Server 2019 CU14 (oder höher).

Stellen Sie sicher, dass der Exchange-Server ordnungsgemäß konfiguriert ist und die im Abschnitt Voraussetzungen für die Aktivierung des erweiterten Schutzes in Exchange Server beschriebenen Anforderungen erfüllt.

Szenario 1: Aktivieren des erweiterten Schutzes auf einem Exchange Server 2019

Führen Sie das Exchange Server 2019 CU14-Setup (oder höher) im beaufsichtigten oder unbeaufsichtigten Modus aus. Das Installationsprogramm konfiguriert den erweiterten Schutz im Rahmen der Installation des Servers, auf dem es ausgeführt wurde.

Szenario 2: Aktivieren des erweiterten Schutzes auf einer Exchange Server 2019, die über den Hybrid-Agent veröffentlicht wird

Führen Sie die Schritte aus, die im Abschnitt Identifizieren von Exchange-Servern beschrieben sind, die mithilfe des Hybrid-Agents veröffentlicht werden , um die Exchange-Server zu identifizieren, die über den Hybrid-Agent veröffentlicht werden.

Führen Sie das Exchange Server 2019 CU14-Setup (oder höher) im unbeaufsichtigten Modus mithilfe des /DoNotEnableEP_FEEWS Parameters aus. Das Aktivieren des erweiterten Schutzes für das virtuelle EWS-Verzeichnis Front-End überspringt:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS

Szenario 3: Überspringen der Aktivierung des erweiterten Schutzes durch Exchange Server 2019 CU14-Setup (oder höher)

Führen Sie das Exchange Server 2019 CU14-Setup (oder höher) im unbeaufsichtigten Modus mithilfe des /DoNotEnableEP Parameters aus. Die Aktivierung des erweiterten Schutzes wird übersprungen:

<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP

Warnung

Wenn Sie den erweiterten Schutz nicht aktivieren, ist Ihr Server anfällig für bekannte Exchange-Sicherheitsrisiken und schwächt den Schutz vor unbekannten Bedrohungen. Es wird empfohlen, dieses Feature zu aktivieren.

Aktivieren des erweiterten Schutzes mithilfe des PowerShell-Skripts

Sie können das ExchangeExtendedProtectionManagement.ps1 Skript verwenden, um den erweiterten Schutz auf einigen oder allen Exchange-Servern gleichzeitig zu aktivieren.

Wichtig

Zum Aktivieren des erweiterten Schutzes in Ihrer Exchange Server-Umgebung müssen viele Änderungen auf allen Exchange-Servern vorgenommen werden. Es wird empfohlen, das von Microsoft bereitgestellte Skript zu verwenden, anstatt diese Änderungen manuell über den IIS-Manager vorzunehmen.

Stellen Sie sicher, dass Sie die neueste Version des Skripts herunterladen, bevor Sie es ausführen, um den erweiterten Schutz zu konfigurieren.

Sie können das Skript auf jedem bestimmten Exchange Server in Ihrer Umgebung ausführen, in der die Exchange-Verwaltungsshell (EMS) installiert ist.

Berechtigungen zum Konfigurieren des erweiterten Schutzes mithilfe des PowerShell-Skripts

Der Benutzer, der das Skript ausführt, muss Mitglied der Organization Management Rollengruppe sein. Das Skript muss über eine Exchange Management Shell (EMS) mit erhöhten Rechten ausgeführt werden.

Skriptkonfigurationsszenarien für erweiterten Schutz

In diesem Abschnitt werden die häufigsten Szenarien zum Konfigurieren des erweiterten Schutzes auf Exchange Server mithilfe des ExchangeExtendedProtectionManagement.ps1 PowerShell-Skripts beschrieben.

Weitere Beispiele und eine Beschreibung der Skriptparameter finden Sie in der Skriptdokumentation .

Szenario 1: Aktivieren des erweiterten Schutzes für alle Exchange Server

Führen Sie das Skript wie folgt aus, um den erweiterten Schutz auf allen Exchange-Servern in Ihrem organization zu aktivieren:

.\ExchangeExtendedProtectionManagement.ps1

Das Skript führt mehrere Überprüfungen durch, um sicherzustellen, dass alle Exchange-Server über die mindestens erforderliche CU- und SU-Version verfügen, um den erweiterten Schutz zu aktivieren. Außerdem wird überprüft, ob alle Exchange-Server dieselbe TLS-Konfiguration verwenden.

Nachdem die Voraussetzungsprüfungen bestanden wurden, aktiviert das Skript den erweiterten Schutz und fügt die erforderlichen SSL-Flags in allen virtuellen Verzeichnissen aller Exchange-Server im Gültigkeitsbereich hinzu. Es wird angehalten, wenn ein Exchange-Server die Anforderungen nicht erfüllt (z. B. wenn eine inkonsistente TLS-Konfiguration erkannt wurde).

Szenario 2: Konfigurieren des erweiterten Schutzes beim Ausführen einer modernen Hybridkonfiguration

Wenn Sie über eine moderne Hybridkonfiguration verfügen, müssen Sie die Aktivierung des erweiterten Schutzes für das virtuelle EWS-Verzeichnis Front-End auf Exchange-Servern überspringen, die mit dem modernen Hybrid-Agent veröffentlicht wurden.

Diese Konfiguration kann mithilfe des ExcludeVirtualDirectories Parameters erfolgen:

.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"

Aktivieren des erweiterten Schutzes mithilfe des IIS-Managers

Wenn Sie den erweiterten Schutz in Ihrer Umgebung manuell aktivieren möchten, ohne das Skript zu verwenden, können Sie die folgenden Schritte ausführen.

Hinweis

Stellen Sie beim manuellen Aktivieren des erweiterten Schutzes sicher, dass für alle virtuellen Verzeichnisse auf Ihren Exchange-Servern extended Protected gemäß der obigen Tabelle konfiguriert ist.

Festlegen des erweiterten Schutzes auf erforderlich oder akzeptieren für in einem virtuellen Verzeichnis

1. Starten Sie auf dem Exchange-Server, auf dem Sie den IIS Manager (INetMgr.exe) erweiterten Schutz konfigurieren möchten.
2. Wechseln Sie zu , Sites und wählen Sie entweder oder aus Default Web Site . Exchange Back End
3. Wählen Sie das virtuelle Verzeichnis aus, das Sie konfigurieren möchten.
4. Auswählen Authentication
5. Wenn Windows Authentication aktiviert ist, wählen Sie Windows Authentication

   

6. Wählen Sie Advanced Settings (auf der rechten Seite) aus, und wählen Sie im öffnenden Fenster den geeigneten Wert aus der Dropdownliste Erweiterter Schutz aus.

   

Festlegen der Erforderlichen SSL-Einstellung für ein virtuelles Verzeichnis

1. Klicken Sie auf das virtuelle Verzeichnis, um die Startseite zu öffnen.

   

2. Auswählen SSL Settings
3. Überprüfen Sie die Require SSL Einstellungen, um sicherzustellen, dass Require SSL für das virtuelle Verzeichnis aktiviert ist.

   

4. Klicken Sie hier Apply , um die neue Einstellung zu bestätigen.

Deaktivieren des erweiterten Schutzes

Sie können das ExchangeExtendedProtectionManagement.ps1 PowerShell-Skript verwenden, um den erweiterten Schutz zu deaktivieren.

Warnung

Das Deaktivieren des erweiterten Schutzes macht Ihren Server anfällig für bekannte Exchange-Sicherheitsrisiken und schwächt den Schutz vor unbekannten Bedrohungen. Es wird empfohlen, dieses Feature aktiviert zu lassen.

Der folgende Befehl deaktiviert die Konfiguration des erweiterten Schutzes für alle Exchange-Server, die online sind, indem der Wert an allen aktuellen Konfigurationsspeicherorten auf Nonefestgelegt wird:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

Sie können auch eine Teilmenge der Server angeben, auf denen der erweiterte Schutz deaktiviert werden soll:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2

Problembehandlung

Dieser Abschnitt enthält bekannte Probleme mit dem erweiterten Schutz und enthält einige Tipps zur Problembehandlung für bekannte Fehlerszenarien.

Bekannte Probleme mit erweitertem Schutz

Tipp

Alle zuvor gemeldeten Probleme mit erweitertem Schutz auf Exchange Server wurden behoben. Es wird dringend empfohlen, das neueste Exchange Server Update für die Version von Exchange zu installieren, die Sie in Ihrem organization ausführen, um von den neuesten Fixes und Verbesserungen zu profitieren.

Problem: Wenn Sie /PrepareSchema, /PrepareDomain oder /PrepareAllDomains in Exchange Server 2019 CU14 unbeaufsichtigt ausführen, wird angezeigt, dass der erweiterte Schutz aktiviert wurde.

Dies ist ein bekanntes Problem mit Exchange Server 2019 CU14, das problemlos ignoriert werden kann. Der erweiterte Schutz ist beim Ausführen /PrepareSchemavon oder /PrepareDomain/PrepareAllDomains nicht aktiviert, um die Umgebung vorzubereiten, wie in der Dokumentation Vorbereiten von Active Directory und Domänen für Exchange Server beschrieben.

Problem: Das Ändern von Berechtigungen für öffentliche Ordner mithilfe eines Outlook-Clients schlägt mit folgendem Fehler fehl: "Die geänderten Berechtigungen können nicht geändert werden."

Dieses Problem tritt auf, wenn der Öffentliche Ordner, für den Sie versuchen, die Berechtigungen zu ändern, in einem sekundären Postfach für öffentliche Ordner gehostet wird, während sich das primäre Postfach für öffentliche Ordner auf einem anderen Server befindet.

Das Problem wurde mit dem neuesten Exchange Server-Update behoben. Befolgen Sie die Anweisungen wie in dieser KB beschrieben, um die Korrektur zu aktivieren.

Warnungen und Fehler während der Ausführung des Skripts für die Konfiguration des erweiterten Schutzes

1. Das Skript zeigt eine Warnung vor bekannten Problemen an und fordert zur Bestätigung auf:

   Um zu verhindern, dass Administratoren in Szenarien geraten, in denen vorhandene Exchange Server Funktionen aufgrund der Aktivierung des erweiterten Schutzes unterbrochen werden, stellt das Skript eine Liste von Szenarien bereit, die bekannte Probleme aufweisen. Lesen und bewerten Sie diese Liste sorgfältig , bevor Sie den erweiterten Schutz aktivieren. Sie können den erweiterten Schutz aktivieren, indem Sie drücken Y.

   

2. Das Skript aktiviert den erweiterten Schutz nicht, da bei einer Voraussetzungsprüfung ein Fehler aufgetreten ist:

   • Kein Exchange-Server führt einen Build aus, der erweiterten Schutz unterstützt:

     Wenn kein Exchange-Server im organization einen Build ausführt, der erweiterten Schutz unterstützt, aktiviert das Skript den erweiterten Schutz auf nicht unterstützten Servern nicht, um sicherzustellen, dass die Server-zu-Server-Kommunikation nicht fehlschlägt.

     Um diesen Fall zu beheben, aktualisieren Sie alle Exchange-Server auf die neueste CU- und SU-Version, und führen Sie das Skript erneut aus, um den erweiterten Schutz zu aktivieren.

   • Tls-Konflikt wurde erkannt:

     Eine gültige und konsistente TLS-Konfiguration ist auf allen Exchange-Servern im Gültigkeitsbereich erforderlich. Wenn die TLS-Einstellungen auf allen Servern im Bereich nicht identisch sind, werden clientseitige Verbindungen mit Postfachservern durch das Aktivieren des erweiterten Schutzes unterbrochen.

     

     Weitere Informationen finden Sie in den bewährten Methoden für die Exchange Server TLS-Konfiguration.

3. Einige Exchange-Server sind nicht verfügbar bzw. nicht erreichbar:

   Das Skript führt mehrere Tests für alle Exchange-Server aus, die sich im Bereich befinden. Wenn einer oder mehrere dieser Server nicht erreichbar sind, schließt das Skript sie aus, da die erforderliche Konfigurationsaktion auf diesen Computern nicht ausgeführt werden kann.

   

   Wenn der Server offline ist, sollten Sie den erweiterten Schutz konfigurieren, sobald er wieder online ist. Wenn der Server aus anderen Gründen nicht erreichbar war, sollten Sie das Skript auf dem Server selbst ausführen, um den erweiterten Schutz zu aktivieren.

Benutzer können nicht über einen oder mehrere Clients auf ihr Postfach zugreifen.

Es kann mehrere Gründe geben, warum einige oder alle Clients damit beginnen können, Benutzern Authentifizierungsfehler zu senden, nachdem der erweiterte Schutz von einem Administrator aktiviert wurde. Wenn dieses Problem auftritt, überprüfen Sie den folgenden Abschnitt:

1. Wenn die TLS-Konfiguration im exchange-organization nicht identisch ist (z. B. wurde die TLS-Konfiguration auf einem der Exchange-Server geändert, nachdem der erweiterte Schutz aktiviert wurde), kann diese Fehlkonfiguration dazu führen, dass Clientverbindungen fehlschlagen. Um dieses Problem zu beheben, überprüfen Sie die Anweisungen zum ordnungsgemäßen Konfigurieren von TLS auf allen Exchange-Servern, und verwenden Sie dann das Skript erneut, um den erweiterten Schutz zu konfigurieren.

2. Überprüfen Sie, ob ssl offloading verwendet wird. Jede SSL-Beendigung führt dazu, dass die Überprüfung des erweiterten Schutzkanalbindungstokens fehlschlägt, da die SSL-Abladung als Man-in-the-Middle betrachtet wird, was durch erweiterten Schutz verhindert wird. Um dieses Problem zu beheben, deaktivieren Sie die SSL-Abladung, und verwenden Sie das Skript, um den erweiterten Schutz erneut zu aktivieren.

3. Benutzer können über Outlook für Windows und Outlook im Web auf ihre E-Mails zugreifen, aber nicht über Nicht-Windows-Clients wie Outlook für Mac, Outlook Mobile oder den nativen iOS-E-Mail-Client. Dies kann passieren, wenn die Einstellung Erweiterter Schutz für EWS und/oder Exchange ActiveSync auf einem oder allen Front-End Servern auf Required festgelegt ist.

   Um dieses Problem zu beheben, führen Sie entweder das ExchangeExtendedProtectionManagement.ps1 Skript mit dem ExchangeServerNames Parameter aus, und übergeben Sie den Namen des Exchange-Servers, der eine falsch konfigurierte Einstellung für erweiterten Schutz aufweist. Sie können das Skript auch ohne Parameter ausführen, um den erweiterten Schutz für alle Server erneut zu überprüfen und zu konfigurieren.

   Alternativ können Sie auch die Einstellung Erweiterter Schutz für diese virtuellen Verzeichnisse verwenden IIS Manager (INetMgr.exe) und in den richtigen Wert ändern, wie in der Tabelle beschrieben. Es wird dringend empfohlen, das Skript zu verwenden, da es nach den richtigen Werten sucht und die Neukonfiguration automatisch durchführt, wenn die Werte nicht wie erwartet festgelegt sind.

4. Wenn einige Clients nach dem Ausführen der oben genannten Schritte immer noch nicht wie erwartet funktionieren, können Sie den erweiterten Schutz vorübergehend zurücksetzen und das Problem an Microsoft melden, indem Sie eine Supportanfrage bei uns öffnen. Führen Sie die Im Abschnitt Deaktivieren des erweiterten Schutzes beschriebenen Schritte aus.

Hybride Frei/Gebucht- oder Postfachmigration funktioniert nicht

Wenn Sie Modern Hybrid verwenden, kann die Aktivierung des erweiterten Schutzes dazu führen, dass Hybridfeatures wie Frei/Gebucht- und Postfachmigration nicht mehr funktionieren, wenn die Konfiguration nicht wie in diesem Artikel beschrieben ausgeführt wurde. Um dieses Problem zu beheben, identifizieren Sie die Hybridserver, die mit dem Hybrid-Agent veröffentlicht wurden, und deaktivieren Sie den erweiterten Schutz im Front-End virtuellen EWS-Verzeichnis auf diesen Servern.

Öffentliche Ordner sind nicht mehr sichtbar/zugänglich

Es gibt zwei Probleme, die sich auf die Konnektivität öffentlicher Ordner auswirken können, wenn erweiterter Schutz aktiviert ist. Befolgen Sie unbedingt die Anweisungen im Abschnitt Erweiterter Schutz und öffentliche Ordner dieses Artikels.

Häufig gestellte Fragen

Frage: Muss das Sicherheitsupdate (SU) vom August 2022 installiert werden, wenn es bereits auf dem vorherigen kumulativen Update (CU) installiert wurde?
Antwort: Ja, es ist erforderlich, die SU vom August 2022 erneut zu installieren, wenn Sie auf einen neueren CU-Build aktualisieren (z. B. Exchange Server 2019 CU11 auf Exchange Server 2019 CU12).

Merken: Wenn Sie planen, das Update sofort durchzuführen (bedeutet CU + SU-Installation), muss der erweiterte Schutz nicht deaktiviert werden. Wenn Sie planen, auf dem CU zu bleiben, ohne die SU sofort zu installieren, müssen Sie den erweiterten Schutz deaktivieren, da der CU-Build (ohne die SU installiert ist) keinen erweiterten Schutz unterstützt und daher möglicherweise Clientkonnektivitätsprobleme auftreten.

Frage: Ist es sicher, den erweiterten Schutz in einer Umgebung zu aktivieren, die Active Directory-Verbunddienste (AD FS) (AD FS) für Outlook im Web (OWA) verwendet?
Antwort: Ja, der erweiterte Schutz hat keine Auswirkungen auf die anspruchsbasierte AD FS-Authentifizierung mit OWA.

Frage: Ist es sicher, den erweiterten Schutz von Windows in einer Umgebung zu aktivieren, die hybride moderne Authentifizierung (Hybrid Modern Auth, HMA) verwendet?
Antwort: Ja, HMA ist von dieser Änderung nicht betroffen. Während der erweiterte Schutz HMA nicht weiter verbessert, können Windows-Authentifizierung weiterhin für Anwendungen verwendet werden, die die moderne Hybridauthentifizierung nicht unterstützen. In Anbetracht dessen wird die Aktivierung des erweiterten Schutzes in jeder Umgebung empfohlen, die noch über lokale Exchange-Dienste verfügt.

Frage: Wirkt sich der erweiterte Schutz auf die hybride moderne Authentifizierung oder die Integration von Microsoft Teams aus?
Antwort: Der erweiterte Schutz wirkt sich nicht auf die Integration von Microsoft Teams oder die moderne Hybridauthentifizierung aus.

Frage: Ich kann nach dem Aktivieren des erweiterten Schutzes mit einem HTTP 400-status-Code nicht auf OWA/ECP zugreifen. Mein OWA/ECP wird über die Entra-Anwendungsproxy veröffentlicht. Wie kann ich vorgehen, um dies zu beheben?
Antwort: Das Veröffentlichen von Exchange OWA/ECP über die Entra-Anwendungsproxy wird nicht unterstützt. Sie müssen OWA/ECP über eine unterstützte Netzwerktopologie nach erweiterten Schutzstandards veröffentlichen.

Frage: Obwohl wir wissen, dass die Verhinderung von MitM-Angriffen wichtig ist, können wir unsere eigenen Geräte mit unseren eigenen Zertifikaten in der Mitte haben?
Antwort: Wenn das Gerät dasselbe Zertifikat wie der Exchange-Server verwendet, können diese verwendet werden.