Partager via

Configurer la protection étendue Windows dans Exchange Server

  • Article

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 :

Valeur Description
Aucune 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

Conseil

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

Avant d’activer la protection étendue, il est essentiel d’effectuer des tests sur tous les produits tiers au sein de votre environnement Exchange Server pour vous assurer qu’ils fonctionnent correctement. Si vous ne savez pas si la protection étendue est prise en charge, vous devez contacter le fournisseur pour confirmation.

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.

Image montrant la connexion du client à un serveur web dans le scénario de déchargement SSL

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.

Image montrant la connexion cliente à un serveur web dans le scénario de pontage SSL

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 Exchange Server.

Site web IIS Répertoire virtuel Valeur 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 Server 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).

Capture d’écran montrant la sortie de l’exécution de l'ExchangeExtendedProtectionManagement.ps1 pour configurer la protection étendue sur tous les serveurs Exchange dans le organization

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. Choisir Authentication
  5. Si Windows Authentication est activé, sélectionnez Windows Authentication

    Image montrant le paramètre Authentification Windows dans le Gestionnaire des services Internet

  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

    Image montrant le menu déroulant Paramètres de protection étendue dans le Gestionnaire des services Internet

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

    Image qui montre les paramètres d’un répertoire virtuel dans le Gestionnaire des services Internet

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

    Image montrant le paramètre Exiger SSL d’un répertoire virtuel dans le Gestionnaire des services Internet

  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

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.

Problème : la création de dossiers publics à l’aide d’un client Outlook échoue avec l’erreur suivante : « Impossible de créer le dossier public. Vous ne disposez pas des autorisations suffisantes pour effectuer cette opération sur cet objet. Consultez le contact du dossier ou votre administrateur système.

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. Notez que ce correctif ne fonctionne pas si un remplacement global pour définir PublicFolderHierarchyHandlerEnabler sur désactivé a été implémenté pour résoudre le problème décrit dans cette base de connaissances.

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.

    Image qui montre l’exclusion de responsabilité du script de configuration de protection étendue.

  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.

      Image montrant l’avertissement TLS mal configuré du script de configuration de la protection étendue.

      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.

    Image qui montre l’avertissement des serveurs inaccessibles du script de configuration protection étendue.

    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.

  • Les utilisateurs ne peuvent pas accéder à leur boîte aux lettres de manière permanente ou sporadique à l’aide d’Outlook pour Windows, d’Outlook pour Mac, d’Outlook Mobile ou du client de messagerie iOS natif :

    • 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.

    • 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.

  • Les utilisateurs peuvent accéder à leurs e-mails à l’aide d’Outlook pour Windows et d’OWA, 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.

  • Les utilisateurs ne peuvent pas accéder à OWA ou ECP à l’aide du navigateur Apple Safari sur macOS ou iOS lorsque l’authentification unique NTLM est utilisée et que la protection étendue a été activée :

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.

Foires aux questions

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épondre: 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).

Se souvenir: 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épondre: 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épondre: 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épondre: 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épondre: 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épondre: Si l’appareil utilise le même certificat que le serveur Exchange, il peut être utilisé.