Publicité en cours de chargement...
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]
Avez-vous apprécié ce contenu ?
A lire également.

Le consortium AGORiA Santé en partenariat avec BIOGROUP obtient la 1ère autorisation de la CNIL permettant d’associer des données de biologie et du SNDS (système national des données de santé)
22 juil. 2025 - 10:23,
Communiqué
- Biogroup & Agoria Santéle 21 juillet 2025 – Le consortium AGORiA Santé est autorisé par la CNIL (Commission nationale de l'informatique et des libertés) à enrichir sa plateforme, entrepôt de données de santé système fils SNDS, avec des données d’analyses de biologie médicales issues du réseau BIOGROUP. Créé en 2021, le co...

Mobisoins Patient : quand soignants et éditeur innovent ensemble au service du patient
08 juil. 2025 - 00:49,
Actualité
- Maellie Vezien, DSIHÀ l’heure où les soins hospitaliers se déploient de plus en plus à domicile, l’implication du patient dans son parcours de santé devient essentielle. Mais comment favoriser son autonomie tout en garantissant une prise en charge sécurisée ? C’est le défi que relèvent l’HAD Vendée et Dicsit Informatiq...

Pilotage des blocs opératoires : l’Anap dévoile une plateforme numérique intégrée pour améliorer la performance et la gouvernance
08 juil. 2025 - 00:26,
Actualité
- DSIHL’Agence nationale de la performance sanitaire et médico-sociale (Anap) franchit un nouveau cap dans le soutien aux établissements de santé avec le lancement d’une plateforme numérique unique dédiée à l’optimisation des blocs opératoires. Ce nouvel outil regroupe 22 ressources opérationnelles destin...

Le Health Data Hub dévoile les 17 lauréats de son premier appel à manifestation d’intérêt portant sur le Catalogue du SNDS
07 juil. 2025 - 23:50,
Communiqué
- Health Data HubLe Catalogue du Système national des données de santé (SNDS) fait référence à l’ensemble des bases de données de partenaires qui sont copiées dans l’environnement technique du Health Data Hub dans l’optique de mutualiser les efforts de croisement avec les données de la base principale de l’Assurance...