Viele Umgebungen haben unterschiedliche Zertifikate zwischen intern (Default Web Site) und extern am Netscaler/WAP oder Firewall. Hier musste ich einige Schritte gehen um passende öffentliche Zertifikate für eine valide Zertifikatskette nach intern zu kaufen/erzeugen und zu binden.
NTLMv1 war zum Glück gar kein Thema mehr.

Bitte konfiguriert eure Exchange Server/Umgebungen immer mit gleichen URLs (intern = extern) für alle virtuellen Verzeichnisse, das hätte es mir auf jeden Fall einfacher gemacht.
Hybrid-Konfigurationen sind auch kein Thema gewesen, da ich immer die Classic-Variante eingerichtet habe.
Hier und da musste ich noch das SSL-Abladen am Outlook-Anywhere deaktivieren aber das war es dann auch schon.

Ihr hoffe ihr habt eure Umgebungen gut im Griff.

Bei Fragen, fragen!

Wie immer berichte ich in diesem Artikel nur von meinen persönlichen Erfahrungen und Erkenntnissen.
Es handelt sich hierbei um keine offizielle Anleitung von Microsoft.
Ein nachhandeln geschieht auf eigene Gefahr.

Tatsächlich sind diese Einstellungen seit 2009 verfügbar und ein Thema von Windows IIS, wird aber jetzt zwingend benötigt, um Sicherheitslücken zu schließen.

Das Flussdiagramm stellt einmal dar, wie der Weg zum schließen der Lücken aussieht.

Hier nun aufgelistet die Einschränkungen:

• Extended Protection kann nicht auf Exchange Server 2013-Servern (Grundsätzlich aber ab Exchange Server 2013 CU23 möglich) aktiviert werden, die über öffentliche Ordner in der Koexistenzumgebung verfügen.
  • Hier werden die Public Folder sonst nicht mehr bei den Endbenutzern erscheinen
• Extended Protection kann nicht auf Exchange Server 2016 CU22 oder Exchange Server 2019 CU11 oder früher aktiviert werden, die die Public Folder Hierarchie hosten.
  • Läuft nur ab 2016 CU23 und 2019 CU12
• Extended Protection funktioniert nicht auf Hybridservern mit der Modern Hybridkonfiguration
  • Features wie Postfachmigration und Frei/Gebucht-Informationen werden unterbrochen
• NTLMv1 wird nicht unterstützt (sollte möglichst sowieso nicht mehr genutzt werden!) Anleitung
  • Nutzt ein Client dennoch NTLMv1, wird er ständig mit Passwortabfragen bombadiert
• SSL-Offload-Szenarien werden nicht unterstützt
  • Die Extended Protection schlägt aufgrund der SSL-Beendigung während des SSL-Offloads fehl. Um Extended Protection in Ihrer Exchange-Umgebung zu aktivieren, verwenden Sie kein SSL-Offloading mit Ihrem Load Balancer.
• Die TLS-Konfiguration
  • Konsistente TLS-Versionen:
    • Überprüfen Sie, dass alle Exchange-Server im Unternehmen die gleiche TLS-Version verwenden. Wenn beispielsweise ein Server TLS 1.2 verwendet, müssen alle anderen Server ebenfalls auf TLS 1.2 konfiguriert sein.
    • Abweichungen in den TLS-Versionen zwischen den Servern können zu Verbindungsproblemen mit den Clients führen und sollten vermieden werden.
  • SchUseStrongCrypto-Registrierungswert:
    • Setzen Sie den Wert des SchUseStrongCrypto-Registrierungswerts auf 1 auf allen Exchange-Servern innerhalb der Organisation.
    • Falls dieser Wert nicht explizit auf 1 festgelegt ist, kann der Standardwert je nach verwendeter .NET-Version interpretiert werden, was zu unerwünschten Konfigurationen führen kann.
  • SystemDefaultTlsVersions-Registrierungswert:
    • Stellen Sie sicher, dass der SystemDefaultTlsVersions-Registrierungswert ebenfalls explizit auf 1 festgelegt ist.
    • Wenn diese Werte nicht wie erwartet festgelegt sind, kann dies zu TLS-Konflikten führen, die wiederum zu Problemen bei der Clientkonnektivität führen.
• Softwarekompatibilität von Drittanbietern
  • Testen Sie Produkte von Drittanbietern in Ihrer Exchange Server-Umgebung, um sicherzustellen, dass sie ordnungsgemäß funktionieren, wenn der erweiterte Schutz aktiviert ist. Ich habe zum Beispiel Antivirenlösungen gesehen, die Verbindungen über einen Proxy senden, um Clientcomputer zu schützen, aber dies verhindert die Kommunikation mit dem Exchange-Server und sollte deaktiviert werden.

SSL-Bridging funktioniert, sofern im Exchange und Load-Balancer das gleiche Zertifikat verwendet wird.

SSL-Offloading für Outlook Anywhere ist standardmäßig aktiviert und muss deaktiviert werden, indem Sie die folgenden Schritte ausführen:

Set-OutlookAnywhere -Identity "EXCH1\rpc (Default Web Site)" -SSLOffloading $false

Sind all diese Einschränkungen geprüft und abgestimmt, kann die Extended Protection via Skript-Unterstützung aktiviert werden.

ExchangeExtendedProtectionManagement.ps1 ist ein Skript zur Automatisierung der Extended Protection des Windows-Authentifizierungsmoduls auf Exchange-Servern. Stellen Sie vor der Konfiguration sicher, dass die TLS-Einstellungen auf allen Servern, auf denen Sie den erweiterten Schutz aktivieren möchten, und auf dem Server, auf dem der Extended Protection bereits aktiviert ist, identisch sind, und dass die erforderlichen anderen Voraussetzungen gegeben sind.

Folgend eine Auflistung mit Beispiel Codezeilen zum ausführen:

PS C:\> .\ExchangeExtendedProtectionManagement.ps1

Einfache Ausführung über alle Server der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames <Array_of_Server_Names>

Ausführen für nur bestimmte Server.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -SkipExchangeServerNames <Array_of_Server_Names>

Ausführen für alle Server außer …

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -FindExchangeServerIPAddresses -OutputFilePath "C:\temp\ExchangeIPs.txt"

Export einer Liste aller Exchange Server IPs in der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig"

Wiederherstellen der IIS-Einstellungen zuvor.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

Aktuelle Einstellungen anzeigen.

Hier noch alle Parameter mit Erläuterung.

Offizieller Microsoft Artikel: Link