Les serveurs Exchange mis au régime protection étendue

Microsoft va activer par défaut, sur certains serveurs Exchange, la protection étendue. De quoi s’agit-il ?

Tous les serveurs Exchange de votre organisation utilisent-ils bien la même version de TLS ? C’est une des conditions pour activer la « protection étendue ».

Cette fonctionnalité vient renforcer l’authentification Windows. Pour atténuer le risque d’attaques de type man-in-the-middle, elle implémente deux éléments. D’une part, la liaison de canal. De l’autre, l’insertion, dans les requêtes, du namespace auquel le client souhaite accéder.

La prise en charge de la protection étendue a été intégrée à Exchanger Server à la faveur de la mise à jour de sécurité d’août 2022. Un script permet d’en automatiser l’activation – indispensable pour corriger certaines failles de sécurité. On peut la déployer sur Exchange 2013 (CU23 au minimum), 2016 (CU22) et 2019 (CU11).

Sur Exchange Server 2019, Microsoft va aller plus loin avec la prochaine mise à jour cumulative (2023 H2, prévue pour cet automne). La protection étendue sera activée par défaut. Si on ne le souhaite pas, il faudra impérativement utiliser l’assistant d’installation en version ligne de commande. Ou bien, dans le cas où on utilise le mode assisté, modifier les paramètres.

Protection étendue… mais compatibilité restreinte

Pour maintenir la compatibilité avec les clients qui ne gèrent pas les mécanismes de protection étendue, il est possible de ne pas forcer la vérification du jeton de liaison de canal. Pour ce qui est de la communication entre serveurs Exchange, en revanche, elle s’interrompra si l’un ne dispose pas au moins de la mise à jour d’août 2022.

Plus globalement, il existe des limites à l’activation de la protection étendue. Entre autres :

> Les dossiers publics hébergés sur les serveurs Exchange 2013 deviennent invisibles dans les environnements qui comprennent aussi des serveurs Exchange 2016 et/ou 2019.

> La protection étendue ne fonctionne pas sur certains serveurs hébergeant une hiérarchie de dossiers publics (en l’occurrence, ceux sous Exchange 2016 CU21 ou toute autre version antérieure et sous Exchange 2019 CU10 ou toute autre version antérieure).

> Elle ne fonctionne pas non plus sur les environnements qui exploitent le déchargement SSL.

> Et pas non plus sur les serveurs en topologie dite « hybride moderne ». Tout du moins, cela perturbe des fonctionnalités telles que la migration de boîtes aux lettres.

À consulter en complément :

OAuth arrive (doucement) sur les serveurs Exchange locaux
Office 365 : de gros trous dans l’authentification
Exchange : une forêt de failles derrière ProxyLogon