Configurer la protection étendue Windows dans Exchange Server

Vue d’ensemble

La protection étendue Windows améliore l’authentification existante dans Windows Server et atténue les attaques de relais d’authentification ou mitM (man-in-the-middle). Cette atténuation est effectuée à l’aide d’informations de sécurité implémentées par le biais d’informations de liaison de canal spécifiées par le biais d’un Channel Binding Token (CBT) qui est principalement utilisé pour les connexions TLS.

La protection étendue est activée par défaut lors de l’installation de Exchange Server 2019 CU14 (ou version ultérieure). Pour plus d’informations, consultez Publication : Mise à jour cumulative 2024 H1 pour Exchange Server.

Sur les versions antérieures de Exchange Server (par exemple, Exchange Server 2016), la protection étendue peut être activée à l’aide du script ExchangeExtendedProtectionManagement.ps1 sur certains ou sur tous les serveurs Exchange.

Terminologie utilisée dans cette documentation

Répertoire virtuel ou vDir

Est utilisé par Exchange Server pour autoriser l’accès aux applications web telles que Exchange ActiveSync, Outlook on the Webet le AutoDiscover service. Plusieurs paramètres de répertoire virtuel peuvent être configurés par un administrateur, notamment les paramètres d’authentification, de sécurité et de création de rapports. La protection étendue est l’un de ces paramètres d’authentification.

Paramètre de protection étendue

Contrôle le comportement de la vérification de ou CBT.Channel Binding Tokens Les valeurs possibles pour ce paramètre sont répertoriées dans le tableau suivant :

Paramètre de protection étendue	Description
Aucun	Spécifie qu’IIS n’effectue pas de vérification CBT.
Autoriser	Spécifie que la vérification CBT est activée, mais pas obligatoire. Ce paramètre permet une communication sécurisée avec les clients qui prennent en charge la protection étendue, tout en prenant en charge les clients qui ne sont pas capables d’utiliser la protection étendue.
Require (Rendre obligatoire)	Cette valeur spécifie que la vérification CBT est requise. Ce paramètre bloque les clients qui ne prennent pas en charge la protection étendue.

Indicateurs SSL

La configuration des paramètres SSL est nécessaire pour garantir que les clients se connectent aux répertoires virtuels IIS d’une manière spécifique avec des certificats clients. Pour activer la protection étendue, les indicateurs SSL requis sont SSL et SSL128.

Déchargement SSL

Arrête la connexion sur un appareil entre le client et le Exchange Server, puis utilise une connexion non chiffrée pour se connecter au Exchange Server.

Pontage SSL

Décrit un processus dans lequel un appareil, situé à la périphérie d’un réseau, déchiffre le trafic SSL, puis le rechiffre avant de l’envoyer au serveur web.

Agent hybride ou hybride moderne

Il s’agit du nom d’une méthode de configuration d’Exchange hybride qui supprime certaines des exigences de configuration pour l’hybride classique (par exemple, les connexions réseau entrantes via votre pare-feu) afin d’activer les fonctionnalités exchange hybrides. Vous pouvez en savoir plus sur cette fonctionnalité ici.

Dossiers publics

Sont conçus pour l’accès partagé et pour faciliter la navigation du contenu dans une hiérarchie profonde. Vous pouvez en savoir plus sur les dossiers publics ici.

Conditions préalables à l’activation de la protection étendue sur Exchange Server

Importante

Nous vous recommandons d’exécuter le script Exchange Server Health Checker pour case activée si toutes les conditions préalables sont remplies sur le serveur Exchange sur lequel la protection étendue doit être activée.

Versions du serveur Exchange qui prennent en charge la protection étendue

La protection étendue est prise en charge sur Exchange Server 2013, 2016 et 2019 à compter des versions d’août 2022 Exchange Server Security Update (SU).

Si votre organization a installé Exchange Server 2016 ou Exchange Server 2019, il doit exécuter la Mises à jour cumulative Exchange trimestrielle de septembre 2021 ou la mise à jour cumulative H1 2022. La mise à jour de sécurité d’août 2022 ou ultérieure doit être installée avant de poursuivre la configuration de la protection étendue.

Si Exchange Server 2013 est installé sur votre organization, Exchange Server doit être sur CU23 avec la mise à jour de sécurité d’août 2022 ou ultérieure installée.

Avertissement

Exchange Server 2013 a atteint la fin du support le 11 avril 2023.

Configuration requise d’Outlook Anywhere

Le déchargement SSL pour Outlook Anywhere est activé par défaut et doit être désactivé avant l’activation de la protection étendue. Suivez les étapes décrites dans l’exemple 3.

Importante

Exchange Server 2019 CU14 (ou version ultérieure) désactive automatiquement le déchargement SSL.Outlook Anywhere Cela fait partie de la protection étendue activée par défaut.

Configuration requise pour la version NTLM

NTLMv1 est faible et ne fournit pas de protection contre les attaques de l’intercepteur (MitM). Il doit être considéré comme vulnérable et ne plus être utilisé.

NTLMv1 ne peut pas être utilisé avec la protection étendue. Si vous appliquez l’utilisation NTLMv1 d’un client à la place de NTLMv2 et que la protection étendue est activée sur vos serveurs Exchange, cette configuration entraîne des invites de mot de passe côté client sans moyen de s’authentifier correctement auprès du serveur Exchange.

Remarque

Pour renforcer la sécurité, nous vous recommandons de passer en revue et de configurer ce paramètre, que vous rencontriez ou non des problèmes.

Si vous rencontrez des invites de mot de passe sur vos clients une fois la protection étendue activée, vous devez case activée la clé de Registre et la valeur suivantes sur votre client et côté Exchange Server :

Clé de Registre : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur de Registre : LmCompatibilityLevel

Il est recommandé de le définir sur une valeur de 5, qui est Send NTLMv2 response only. Refuse LM & NTLM. Il doit être défini au moins sur une valeur de 3 qui est Send NTLMv2 response only.

Si vous supprimez la valeur, le système d’exploitation applique la valeur par défaut du système. Sur Windows Server 2008 R2 et versions ultérieures, nous la traitons comme si elle était définie sur 3.

Si vous souhaitez gérer le paramètre de manière centralisée, vous pouvez le faire à l’aide de stratégie de groupe :

Emplacement de la stratégie : Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Pour plus d’informations, consultez Sécurité réseau : niveau d’authentification du gestionnaire de réseau local

Conditions requises pour TLS

Avant d’activer la protection étendue, vous devez vous assurer que toutes les configurations TLS sont cohérentes sur tous les serveurs Exchange. Par exemple, si l’un des serveurs utilise TLS 1.2, vous devez vous assurer que tous les serveurs du organization sont configurés à l’aide TLS 1.2de . Toute variation de l’utilisation de la version TLS entre les serveurs peut entraîner l’échec des connexions client ou serveur à serveur.

En plus de cette exigence, la valeur de la valeur de SchUseStrongCrypto Registre doit être définie sur la valeur sur 1 tous les serveurs Exchange au sein du organization.

Si cette valeur n’est pas explicitement définie sur 1, la valeur par défaut de cette clé peut être interprétée comme 0 ou 1 en fonction de la version de .NET utilisée par les fichiers binaires Exchange Server et il est possible que vous rencontriez des problèmes de connexion dans la communication de serveur à serveur. Cela peut se produire, en particulier si différentes versions de Exchange Server (par exemple, Exchange Server 2016 et Exchange Server 2019) sont en cours d’utilisation.

Il en va de même pour la valeur de SystemDefaultTlsVersions Registre, qui doit également être explicitement définie sur une valeur de 1.

Si ces valeurs de Registre ne sont pas configurées comme prévu, cette configuration incorrecte peut entraîner une incompatibilité TLS dans la communication de serveur à serveur ou de client à serveur et, par conséquent, peut entraîner des problèmes de connectivité.

Reportez-vous à ce guide Exchange Server bonnes pratiques de configuration TLS pour configurer les paramètres TLS requis sur vos serveurs Exchange.

Compatibilité des logiciels tiers

Veillez à tester tous les produits tiers qui s’exécutent dans votre environnement de Exchange Server pour vous assurer qu’ils fonctionnent correctement si la protection étendue est activée.

Nous avons vu, par exemple, des solutions antivirus, qui envoyaient des connexions via un serveur proxy local afin de protéger l’ordinateur client. Un tel scénario empêcherait la communication avec le serveur Exchange et devrait être désactivé, car il est considéré comme une connexion mitM (man-in-the-middle), qui sera bloquée par la protection étendue.

Scénarios susceptibles d’affecter la connectivité du client lorsque la protection étendue a été activée

Scénarios de déchargement SSL

La protection étendue n’est pas prise en charge dans les environnements qui utilisent le déchargement SSL. L’arrêt SSL pendant le déchargement SSL entraîne l’échec de la protection étendue. Pour activer la protection étendue dans votre environnement Exchange, vous ne devez pas utiliser le déchargement SSL avec vos équilibreurs de charge.

Scénarios de pontage SSL

La protection étendue est prise en charge dans les environnements qui utilisent le pontage SSL sous certaines conditions. Pour activer la protection étendue dans votre environnement Exchange à l’aide du pontage SSL, vous devez utiliser le même certificat SSL sur Exchange et vos équilibreurs de charge. L’utilisation de différents certificats entraîne l’échec du jeton de liaison de canal de protection étendue case activée et, par conséquent, empêche les clients de se connecter au serveur Exchange.

Scénarios de protection étendue et de dossier public

La section suivante décrit les scénarios de dossier public, qui peuvent entraîner des échecs lorsque la protection étendue est activée.

La protection étendue ne peut pas être activée sur les serveurs Exchange Server 2013 avec des dossiers publics dans un environnement de coexistence

Pour activer la protection étendue sur Exchange Server 2013, vérifiez qu’aucun dossier public n’est hébergé sur Exchange Server 2013. Si vous avez une coexistence de Exchange Server 2013 avec Exchange Server 2016 ou Exchange Server 2019, vous devez migrer vos dossiers publics vers Exchange Server 2016 ou Exchange Server 2019 avant d’activer la protection étendue. Une fois que la protection étendue a été activée et qu’il existe des dossiers publics sur Exchange Server 2013, ils n’apparaissent plus pour les utilisateurs finaux !

Avertissement

Exchange Server 2013 a atteint la fin du support le 11 avril 2023.

La protection étendue ne peut pas être activée sur Exchange Server CU22 2016 ou Exchange Server 2019 CU11 ou une version antérieure qui héberge une hiérarchie de dossiers publics

Si vous disposez d’un environnement contenant Exchange Server 2016 CU22 ou Exchange Server 2019 CU11 ou une version antérieure et que vous utilisez dossiers publics, vous devez confirmer la version du serveur qui héberge la hiérarchie des dossiers publics avant d’activer la protection étendue .

Assurez-vous que le serveur, qui héberge la hiérarchie des dossiers publics, est mis à niveau vers Exchange Server cu23 2016 ou Exchange Server 2019 CU12 (ou version ultérieure) avec la dernière Mises à jour de sécurité installée. Déplacez la hiérarchie de dossiers publics vers un Exchange Server qui exécute une version requise si vous ne pouvez pas mettre à niveau le serveur Exchange vers une version prise en charge.

Le tableau suivant peut être utilisé pour clarifier :

Version d’Exchange	Mise à jour cumulative installée	Unité de su installée	Héberge les boîtes aux lettres PF	Ep est-il pris en charge ?
Exchange 2013	CU23	Août 2022 (ou version ultérieure)	Non	Oui
Exchange 2016	CU22	Août 2022 (ou version ultérieure)	Aucune boîte aux lettres de hiérarchie	Oui
Exchange 2016	CU23 (2022 H1) ou version ultérieure	Août 2022 (ou version ultérieure)	N’importe lequel	Oui
Exchange 2019	CU11	Août 2022 (ou version ultérieure)	Aucune boîte aux lettres de hiérarchie	Oui
Exchange 2019	CU12 (2022 H1) ou version ultérieure	Août 2022 (ou version ultérieure)	N’importe lequel	Oui
Toute autre version	Toute autre cu	Toute autre unité de su	N’importe lequel	Non

Protection étendue et configuration hybride moderne

La section suivante couvre Exchange Server scénarios hybrides modernes, qui peuvent entraîner des échecs lorsque la protection étendue est activée.

La protection étendue ne peut pas être entièrement configurée sur les serveurs Exchange publiés à l’aide de l’agent hybride

Dans une configuration hybride moderne, les serveurs Exchange sont publiés via un agent hybride, qui proxèle les appels Exchange Online au serveur Exchange.

L’activation de la protection étendue sur les serveurs Exchange publiés via l’agent hybride peut entraîner une interruption des fonctionnalités hybrides telles que les déplacements de boîtes aux lettres et les appels de disponibilité s’ils ne sont pas effectués correctement. Il est donc important d’identifier tous les serveurs Exchange, qui sont publiés à l’aide d’un agent hybride et de ne pas activer la protection étendue sur le Front-End répertoire virtuel EWS sur eux.

Identification des serveurs Exchange publiés à l’aide de l’agent hybride

Si vous n’avez pas de liste de serveurs publiés via l’agent hybride, vous pouvez effectuer les étapes suivantes pour les identifier. Ces étapes ne sont pas nécessaires si vous exécutez un déploiement classique Exchange Server hybride.

1. Connectez-vous à un ordinateur sur lequel l’agent hybride est installé et ouvrez le module PowerShell de l’agent hybride. Exécutez Get-HybridApplication pour identifier le TargetUri utilisé par l’agent hybride.
2. Le TargetUri paramètre vous donne le nom de domaine complet du serveur Exchange, qui est configuré pour être utilisé par l’agent hybride.
   • Déduisez l’identité du serveur Exchange à l’aide du nom de domaine complet et notez le nom du serveur Exchange.
   • Si vous utilisez une URL Load Balancer dans TargetUri, vous devez identifier tous les serveurs Exchange sur lesquels le Client Access rôle est installé et accessibles derrière l’URL Load Balancer.

Importante

La protection étendue ne doit pas être activée sur le répertoire virtuel Front-End EWS sur les serveurs Exchange qui sont publiés via un agent hybride.

Nous vous recommandons les étapes suivantes pour protéger les serveurs Exchange, qui ont été publiés via l’agent hybride :

Remarque

Dans le scénario suivant, l’agent hybride est installé sur un serveur qui n’exécute PAS Exchange Server. En outre, ce serveur se trouve dans un segment réseau différent des serveurs Exchange de production.

1. Pour les serveurs Exchange publiés via l’agent hybride, les connexions entrantes doivent être limitées par un pare-feu afin d’autoriser les connexions uniquement à partir de l’ordinateur sur lequel l’agent hybride est installé. Cela n’affecte pas les communications sortantes des serveurs Exchange vers Exchange Online.
2. Aucune boîte aux lettres ne doit être hébergée sur les serveurs Exchange, qui ont été publiés via l’agent hybride. Les boîtes aux lettres existantes doivent être migrées vers d’autres serveurs de boîtes aux lettres.

Activation de la protection étendue

La protection étendue est automatiquement activée pendant Exchange Server configuration cu14 (ou ultérieure) 2019. Sur les versions antérieures de Exchange Server, qui prennent en charge la protection étendue, il peut être activé via un script fourni par Microsoft (recommandé) ou manuellement via le Gestionnaire des services Internet.

Pour configurer correctement la protection étendue, chaque répertoire virtuel sur tous les serveurs Exchange dans le organization (à l’exception des serveurs de transport Edge) doit être défini sur la valeur prescrite de Extended Protection et sslFlags.

Le tableau suivant récapitule les paramètres nécessaires pour chaque répertoire virtuel sur les versions prises en charge de Microsoft Exchange.

Site web IIS	Répertoire virtuel	Protection étendue recommandée	SslFlags recommandé
Default Website	API	Required	Ssl,Ssl128
Default Website	AutoDiscover	Off	Ssl,Ssl128
Default Website	ECP	Required	Ssl,Ssl128
Default Website	EWS	Accept (IU) / Allow (Script)	Ssl,Ssl128
Default Website	MAPI	Required	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync	Accept (IU) / Allow (Script)	Ssl,Ssl128
Default Website	Microsoft-Server-ActiveSync/Proxy	Accept (IU) / Allow (Script)	Ssl,Ssl128
Default Website	OAB	Accept (IU) / Allow (Script)	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

Remarque

Après la version initiale, nous avons mis à jour Default Website/OAB pour être Accept/Allow au lieu de Required et Default Website/PowerShell pour être Off au lieu de Required. La modification de Default Website/OAB est due au fait que Outlook pour Mac clients ne peuvent plus télécharger le carnet d’adresses en mode hors connexion avec le Required paramètre . La modification apportée à Default Website/PowerShell est due au fait que la configuration par défaut Exchange Server n’autorise pas les connexions à l’aide de l’authentification NTLM à PowerShell Front-End répertoire virtuel et, par conséquent, la protection étendue n’est pas applicable.

L’apport de modifications au Default Website/PowerShell répertoire virtuel n’est pas pris en charge, sauf avis explicite du service client et du support technique Microsoft (CSS).

Activation de la protection étendue à l’aide du programme d’installation Exchange Server 2019 CU14 (ou version ultérieure)

Avec Exchange Server 2019 CU14 et versions ultérieures, le programme d’installation de la mise à jour cumulative (CU) Exchange Server 2019 active automatiquement la protection étendue sur le serveur de boîtes aux lettres sur lequel le programme d’installation est exécuté. Cela se produit pour toute nouvelle installation ou lors de la mise à niveau d’une installation Exchange Server existante vers la dernière version.

Deux nouveaux paramètres peuvent être utilisés en mode d’installation sans assistance pour contrôler le comportement de protection étendue activée par défaut.

Les paramètres peuvent être utilisés pour ignorer l’activation automatique de la protection étendue (/DoNotEnableEP) ou pour ne pas activer la protection étendue sur le répertoire virtuel Front-End EWS (/DoNotEnableEP_FEEWS).

Avertissement

La désactivation de la protection étendue rend votre serveur vulnérable aux vulnérabilités Exchange connues et affaiblit la protection contre les menaces inconnues. Nous vous recommandons de laisser cette fonctionnalité activée.

Scénarios de configuration du programme d’installation de cu de protection étendue

Dans cette section, nous fournissons les scénarios les plus courants pour la configuration de la protection étendue sur Exchange Server à l’aide du programme d’installation de mise à jour cumulative (CU) Exchange Server 2019 2019 (ou version ultérieure).

Assurez-vous que le serveur Exchange est correctement configuré et répond aux exigences décrites dans la section Prérequis pour l’activation de la protection étendue sur Exchange Server.

Scénario 1 : Activer la protection étendue sur un Exchange Server 2019

Exécutez le programme d’installation Exchange Server 2019 CU14 (ou version ultérieure) en mode assisté ou sans assistance. Le programme d’installation configure la protection étendue dans le cadre de l’installation du serveur sur lequel il a été exécuté.

Scénario 2 : Activer la protection étendue sur un Exchange Server 2019 publié via un agent hybride

Suivez les étapes décrites dans la section Identification des serveurs Exchange publiés à l’aide de l’agent hybride pour identifier les serveurs Exchange publiés via l’agent hybride.

Exécutez le programme d’installation Exchange Server 2019 CU14 (ou version ultérieure) en mode sans assistance à l’aide du /DoNotEnableEP_FEEWS paramètre . Il ignore l’activation de la protection étendue sur le répertoire virtuel Front-End EWS :

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

Scénario 3 : Ignorer l’activation de la protection étendue par Exchange Server 2019 CU14 (ou version ultérieure)

Exécutez le programme d’installation Exchange Server 2019 CU14 (ou version ultérieure) en mode sans assistance à l’aide du /DoNotEnableEP paramètre . Il ignore l’activation de la protection étendue :

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

Avertissement

Le fait de ne pas activer la protection étendue rend votre serveur vulnérable aux vulnérabilités Exchange connues et affaiblit la protection contre les menaces inconnues. Nous vous recommandons d’activer cette fonctionnalité.

Activation de la protection étendue à l’aide du script PowerShell

Vous pouvez utiliser le script ExchangeExtendedProtectionManagement.ps1 pour activer la protection étendue sur tout ou partie de vos serveurs Exchange à la fois.

Importante

L’activation de la protection étendue dans votre environnement Exchange Server implique d’apporter de nombreuses modifications sur tous les serveurs Exchange. Nous vous recommandons d’utiliser le script fourni par Microsoft au lieu d’apporter ces modifications manuellement via le Gestionnaire iis.

Veillez à télécharger la dernière version du script avant de l’exécuter pour configurer la protection étendue.

Vous pouvez exécuter le script sur n’importe quel Exchange Server spécifique dans votre environnement, sur lequel exchange Management Shell (EMS) est installé.

Autorisations pour configurer la protection étendue à l’aide du script PowerShell

L’utilisateur qui exécute le script doit être membre du Organization Management groupe de rôles. Le script doit être exécuté à partir d’un environnement de ligne de commande Exchange Management Shell (EMS) avec élévation de privilèges.

Scénarios de configuration de script de protection étendue

Dans cette section, nous fournissons les scénarios les plus courants de configuration de la protection étendue sur Exchange Server à l’aide du script PowerShellExchangeExtendedProtectionManagement.ps1.

Pour obtenir d’autres exemples et une description des paramètres de script, consultez la documentation sur les scripts.

Scénario 1 : Activer la protection étendue sur tous les Exchange Server

Exécutez le script comme suit pour activer la protection étendue sur tous les serveurs Exchange au sein de votre organization :

.\ExchangeExtendedProtectionManagement.ps1

Le script effectue plusieurs vérifications pour s’assurer que tous les serveurs Exchange sont sur la version minimale de cu et su requise pour activer la protection étendue. Il vérifie également si tous les serveurs Exchange utilisent la même configuration TLS.

Une fois les vérifications des prérequis passées, le script active la protection étendue et ajoute les indicateurs SSL requis sur tous les répertoires virtuels de tous les serveurs Exchange dans l’étendue. Elle s’arrête au cas où un serveur Exchange ne répond pas aux exigences (par exemple, si une configuration TLS incohérente a été détectée).

Scénario 2 : Configurer la protection étendue lors de l’exécution d’une configuration hybride moderne

Si vous avez une configuration hybride moderne, vous devez ignorer l’activation de la protection étendue sur le répertoire virtuel Front-End EWS sur les serveurs Exchange, qui ont été publiés à l’aide de l’agent hybride moderne.

Cette configuration peut être effectuée à l’aide du ExcludeVirtualDirectories paramètre :

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

Activer la protection étendue à l’aide du Gestionnaire des services Internet

Si vous souhaitez activer la protection étendue dans votre environnement manuellement sans utiliser le script, vous pouvez effectuer les étapes suivantes.

Remarque

Lorsque vous activez manuellement la protection étendue, vérifiez que tous les répertoires virtuels de vos serveurs Exchange disposent d’une protection étendue configurée comme décrit dans le tableau ci-dessus.

Définir la protection étendue sur obligatoire ou accepter pour sur un répertoire virtuel

1. Lancez sur IIS Manager (INetMgr.exe) le serveur Exchange sur lequel vous souhaitez configurer la protection étendue
2. Accédez à Sites et sélectionnez ou Default Web SiteExchange Back End
3. Sélectionnez le répertoire virtuel que vous souhaitez configurer
4. Sélectionnez Authentication
5. Si Windows Authentication est activé, sélectionnez Windows Authentication

   

6. Sélectionnez Advanced Settings (sur le côté droit) et dans la fenêtre d’ouverture, sélectionnez la valeur appropriée dans la liste déroulante Protection étendue

   

Définir le paramètre SSL requis pour un répertoire virtuel

1. Cliquez sur le répertoire virtuel pour ouvrir la page d’accueil

   

2. Sélectionnez SSL Settings
3. Vérifiez les Require SSL paramètres pour vous assurer que Require SSL est activé pour le répertoire virtuel

   

4. Cliquez Apply pour confirmer le nouveau paramètre

Désactivation de la protection étendue

Vous pouvez utiliser le script PowerShellExchangeExtendedProtectionManagement.ps1pour désactiver la protection étendue.

Avertissement

La désactivation de la protection étendue rend votre serveur vulnérable aux vulnérabilités Exchange connues et affaiblit la protection contre les menaces inconnues. Nous vous recommandons de laisser cette fonctionnalité activée.

La commande suivante désactive la configuration de protection étendue pour tous les serveurs Exchange qui sont en ligne en définissant la valeur à tous les emplacements de configuration actuels sur None:

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

Vous pouvez également spécifier un sous-ensemble de serveurs sur lesquels la protection étendue doit être désactivée :

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

Résolution des problèmes

Cette section contient les problèmes connus qui existent avec la protection étendue et répertorie quelques conseils de dépannage pour les scénarios d’échec connus.

Problèmes connus liés à la protection étendue

Conseil

Tous les problèmes précédemment signalés avec la protection étendue sur Exchange Server ont été résolus. Nous vous recommandons vivement d’installer la dernière mise à jour Exchange Server pour la version d’Exchange que vous exécutez dans votre organization afin de bénéficier des derniers correctifs et améliorations.

Problème : lorsque vous exécutez /PrepareSchema, /PrepareDomain ou /PrepareAllDomains dans Exchange Server configuration du mode sans assistance CU14 2019 montre que la protection étendue a été activée

Il s’agit d’un problème connu avec Exchange Server 2019 CU14 qui peut être ignoré en toute sécurité. La protection étendue n’est pas activée lors de l’exécution /PrepareSchemade , /PrepareDomain ni /PrepareAllDomains pour préparer l’environnement comme décrit dans la documentation Préparer Active Directory et les domaines pour Exchange Server.

Problème : La modification des autorisations pour les dossiers publics à l’aide d’un client Outlook échoue avec l’erreur suivante : « Les autorisations modifiées ne peuvent pas être modifiées »

Ce problème se produit si le dossier public pour lequel vous essayez de modifier les autorisations est hébergé sur une boîte aux lettres de dossier public secondaire alors que la boîte aux lettres de dossier public principale se trouve sur un autre serveur.

Le problème a été résolu avec la dernière mise à jour Exchange Server. Suivez les instructions décrites dans cette base de connaissances pour activer le correctif.

Avertissements et erreurs lors de l’exécution du script de configuration de la protection étendue

1. Le script affiche un avertissement des problèmes connus et demande une confirmation :

   Pour empêcher les administrateurs de s’exécuter dans des scénarios où des fonctions Exchange Server existantes sont interrompues en raison de l’activation de la protection étendue, le script fournit une liste de scénarios qui présentent des problèmes connus. Lisez et évaluez attentivement cette liste avant d’activer la protection étendue. Vous pouvez continuer à activer la protection étendue en appuyant sur Y.

   

2. Le script n’active pas la protection étendue, car un case activée prérequis a échoué :

   • Aucun serveur Exchange n’exécute une build qui prend en charge la protection étendue :

     Si aucun serveur Exchange dans le organization n’exécute une build qui prend en charge la protection étendue, le script n’active pas la protection étendue sur les serveurs non pris en charge pour s’assurer que la communication de serveur à serveur n’échoue pas.

     Pour résoudre ce cas, mettez à jour tous les serveurs Exchange avec la dernière cu et su, puis réexécutez le script pour activer la protection étendue.

   • Une incompatibilité TLS a été détectée :

     Une configuration TLS valide et cohérente est requise sur tous les serveurs Exchange dans l’étendue. Si les paramètres TLS sur tous les serveurs de l’étendue ne sont pas les mêmes, l’activation de la protection étendue interrompt les connexions client aux serveurs de boîtes aux lettres.

     

     Pour plus d’informations, lisez les bonnes pratiques de configuration TLS Exchange Server.

3. Certains serveurs Exchange ne sont pas disponibles/accessibles :

   Le script effectue plusieurs tests sur tous les serveurs Exchange, qui sont dans l’étendue. Si un ou plusieurs de ces serveurs ne sont pas accessibles, le script les exclut, car il ne peut pas effectuer l’action de configuration requise sur ces ordinateurs.

   

   Si le serveur est hors connexion, vous devez configurer la protection étendue dès qu’il est de nouveau en ligne. Si le serveur était inaccessible pour d’autres raisons, vous devez exécuter le script sur le serveur lui-même pour activer la protection étendue.

Les utilisateurs ne peuvent pas accéder à leur boîte aux lettres via un ou plusieurs clients

Il peut y avoir plusieurs raisons pour lesquelles certains ou tous les clients peuvent commencer à attribuer des erreurs d’authentification aux utilisateurs après l’activation de la protection étendue par un administrateur. Si ce problème se produit, case activée la section suivante :

1. Si la configuration TLS dans l’organization Exchange n’est pas la même (par exemple, la configuration TLS a été modifiée sur l’un des serveurs Exchange après l’activation de la protection étendue), cette configuration incorrecte peut entraîner l’échec des connexions client. Pour résoudre ce problème, case activée les instructions pour configurer correctement TLS sur tous les serveurs Exchange, puis utilisez le script pour configurer à nouveau la protection étendue.

2. Vérifiez si le déchargement SSL est utilisé. Toute terminaison SSL entraîne l’échec du jeton de liaison de canal de protection étendue case activée, car le déchargement SSL est considéré comme un homme dans le milieu, ce qui est empêché par la protection étendue. Pour résoudre ce problème, désactivez le déchargement SSL et utilisez le script pour réactiver la protection étendue.

3. Les utilisateurs peuvent accéder à leurs e-mails à l’aide d’Outlook pour Windows et d’Outlook sur le web, mais pas via des clients non Windows comme Outlook pour Mac, Outlook Mobile ou le client de messagerie natif iOS. Cela peut se produire si le paramètre Protection étendue pour EWS et/ou Exchange ActiveSync est défini Required sur un ou sur tous les serveurs Front-End.

   Pour résoudre ce problème, exécutez le ExchangeExtendedProtectionManagement.ps1 script avec le ExchangeServerNames paramètre et transmettez le nom du serveur Exchange, qui a un paramètre de protection étendue mal configuré. Vous pouvez également exécuter le script sans paramètre pour case activée et configurer à nouveau la protection étendue pour tous les serveurs

   Vous pouvez également utiliser IIS Manager (INetMgr.exe) et modifier le paramètre De protection étendue pour ces répertoires virtuels en lui affectant la valeur appropriée, comme indiqué dans le tableau. Nous vous recommandons vivement d’utiliser le script car il vérifie les valeurs correctes et effectue la reconfiguration automatiquement si les valeurs ne sont pas définies comme prévu.

4. Si, après avoir suivi les étapes ci-dessus, certains clients ne fonctionnent toujours pas comme prévu, vous pouvez restaurer temporairement la protection étendue et signaler le problème à Microsoft en ouvrant un dossier de support avec nous. Suivez les étapes décrites dans la section Désactivation de la protection étendue .

La disponibilité hybride ou la migration de boîtes aux lettres ne fonctionne pas

Si vous utilisez l’hybride moderne, l’activation de la protection étendue peut entraîner l’arrêt des fonctionnalités hybrides telles que la disponibilité et la migration des boîtes aux lettres si la configuration n’a pas été effectuée comme décrit dans cet article. Pour résoudre ce problème, identifiez les serveurs hybrides qui ont été publiés à l’aide de l’agent hybride et désactivez la protection étendue sur le répertoire virtuel Front-End EWS sur ces serveurs.

Les dossiers publics ne sont plus visibles/accessibles

Deux problèmes peuvent affecter la connectivité des dossiers publics lorsque la protection étendue est activée. Veillez à suivre les instructions décrites dans la section Protection étendue et dossiers publics de cet article.

FAQ

Question: Est-il nécessaire d’installer la mise à jour de sécurité (SU) d’août 2022 si elle était déjà installée sur la mise à jour cumulative précédente ?
Réponse: Oui, il est nécessaire d’installer à nouveau l’unité de mise à jour d’août 2022 si vous effectuez une mise à jour vers une build cu plus récente (par exemple, Exchange Server 2019 CU11 vers Exchange Server CU12 2019).

Rappelez-vous: Si vous envisagez d’effectuer la mise à jour immédiatement (installation cu + SU), la protection étendue n’a pas besoin d’être désactivée. Si vous envisagez de rester sur la mise à jour cumulative sans installer immédiatement l’unité de mise à jour, vous devez désactiver la protection étendue, car la build cu (sans l’installation de l’unité de service) ne prend pas en charge la protection étendue et, par conséquent, vous pouvez rencontrer des problèmes de connectivité client.

Question: Est-il sûr d’activer la protection étendue dans un environnement qui utilise Services ADFS (AD FS) pour Outlook sur le web (OWA) ?
Réponse: Oui, la protection étendue n’a pas d’impact sur l’authentification basée sur les revendications AD FS avec OWA.

Question: Est-il sûr d’activer la protection étendue Windows dans un environnement qui utilise l’authentification moderne hybride (HMA) ?
Réponse: Oui, HMA ne sera pas impacté par cette modification. Bien que la protection étendue n’améliore pas davantage HMA, Authentification Windows peut toujours être utilisé pour les applications qui ne prennent pas en charge l’authentification moderne hybride. Compte tenu de cela, l’activation de la protection étendue est recommandée dans tout environnement éligible qui dispose encore de services Exchange locaux.

Question: La protection étendue affecte-t-elle l’intégration de l’authentification moderne hybride ou de Microsoft Teams ?
Réponse: La protection étendue n’affecte pas l’intégration de Microsoft Teams ou l’authentification moderne hybride.

Question: Je ne parviens pas à accéder à OWA/ECP après avoir activé la protection étendue avec un code http 400 status, mon OWA/ECP est publié via le Proxy d'application Entra. Que puis-je faire pour résoudre ce problème ?
Réponse: La publication d’Exchange OWA/ECP via le Proxy d'application Entra n’est pas prise en charge. Vous devez publier OWA/ECP via une topologie de réseau prise en charge par les normes de protection étendue.

Question: Bien que nous comprenions que la prévention des attaques MitM est importante, pouvons-nous avoir nos propres appareils au milieu avec nos propres certificats ?
Réponse: Si l’appareil utilise le même certificat que le serveur Exchange, il peut être utilisé.