Correctif de sécurité Exchange de juillet : ce qu’il faut savoir avant de tout casser

Attention, seules les deux dernières CU pour Exchange 2016 et 2019, ainsi que la dernière CU pour Exchange 2013 sont en capacité à être patchés.

Voici les correctifs correspondants :

- Exchange 2013 CU23 : KB5004778 [3]
- Exchange 2016 CU20 et 21 : KB5004779 [4]
- Exchange 2019 CU9 et 10 : KB5004780 [5]

Le correctif ne remontant pas forcément dans Windows Update, une installation manuelle risque de s’avérer nécessaire. Une exécution depuis un shell / prompt « exécuté en tant qu’administrateur » est fortement recommandé par Microsoft pour éviter les problèmes d’arrêts de services en cours de déploiement. Malgré cela, il est possible que vous soyez obligé de tuer manuellement certains processus.

Une fois installé, le script HealthChecker [6] pourra permettre de vérifier sa bonne application :

Oui mais voilà, comme beaucoup d’autres clients Exchange, vous risquez de constater qu’après le déploiement du correctif, vos utilisateurs se connectant au serveur à jour sont confrontés à un message d’erreur lors de leur tentative d’authentification sur l’interface Web OWA. Si par chance vous avez plusieurs serveurs et qu’ils ne sont pas tous à jour, le problème sera aléatoire pour les utilisateurs.

Vous avez lancé les scripts UpdateCas.ps1 et UpdateConfigFiles.ps1 permettant de reconstruire les interfaces Web OWA et ECP, mais rien n’y fait.

En regardant le message d’erreur sur le serveur venant d’être mis à jour, vous pourrez en savoir un peu plus :

Si vous commencez à vous dire que Microsoft a envie de vous pousser vers sa solution cloud Office 365, dites-vous que vous êtes probablement en train de devenir complotiste…

Bon le problème vient du certificat utilisé pour l’authentification, même si le certificat original est valide et non expiré, ça coince… À noter qu’aucun nom de domaine n’est défini pour le certificat d’origine…

La préco de Microsoft est de générer un nouveau certificat, comme si celui-ci était arrivé à expiration. Qu’à cela ne tienne, Microsoft propose une procédure :

Une fois le certificat créé, attribué pour la partie authentification, et les services redémarrés, vous pensez être sorti d’affaire ! Rebelote même message ! Si par chance vous avez un DAG et que vous avez des serveurs qui n’ont pas encore le correctif, vous allez pouvoir limiter la casse en isolant votre serveur à jour.

Vous allez me dire, pourquoi ça ne fonctionne toujours pas, alors que vous avez suivi à la lettre la procédure et que ça fonctionne toujours sur vos serveurs non patchés ?

En vérifiant quel certificat est utilisé pour l’authentification :

Vous constaterez que vous utilisez le bon certificat, et qu’il est bien valide et non expiré. Alors pourquoi le problème n’est toujours pas résolu ???

Maintenant, si vous affichez les détails du message d’erreur OWA côté poste client, vous pourrez voir qu’Exchange, même avec un serveur réglé sur l’heure locale (UTC+2 avec l’heure d’été en France métropolitaine), s’appuie sur l’heure UTC dans son processus d’authentification :

Ici le message d’erreur affiche l’heure UTC 13H48, alors qu’il est 15H48 en France métropolitaine et que mon certificat n’est valide qu’à partir de 15H41.

On peut donc en conclure qu’avant la publication de ce correctif, Exchange ne prenait pas en considération la valeur du champ « Non valide avant » puisqu’il est possible de s’authentifier sur les serveurs non patchés utilisant ce même certificat, contrairement au serveur mis à jour.
En remettant la vapeur sur votre serveur à jour après avoir attendu 17H41, soit 15H41 UTC, vous constaterez qu’il redevient enfin fonctionnel.

Patcher n’est jamais sans risques, même si le but est bien de les réduire. Vous êtes prévenus ;-p

[1] 

[2] 

[3] 

[4] 

[5] 

[6]