Microsoft vient de publier un rappel important sur un changement de comportement Windows qui peut surprendre en production : certaines actions administratives ou authentifications réseau peuvent maintenant échouer lorsque plusieurs machines partagent des identifiants système dupliqués.
Dit autrement : si des postes ou serveurs ont été clonés sans Sysprep, Windows peut désormais le détecter et bloquer certaines authentifications.
Ce n’est pas un bug mais un durcissement de sécurité.
Le sujet en une phrase
Depuis les mises à jour Windows publiées à partir d’août / septembre 2025, Windows renforce la validation de l’identité machine dans certains scénarios d’authentification Kerberos et NTLM, notamment pour éviter des contournements liés au loopback, au filtrage de token et à l’élévation de privilèges. Le changement concerne Windows 11 24H2, Windows 11 25H2 et Windows Server 2025.
Le cas typique qui pose problème : des machines clonées sans avoir été correctement généralisées avec Sysprep.
Pourquoi Microsoft durcit ce comportement
Le problème n’est pas nouveau : quand une machine Windows est clonée n’importe comment, elle peut conserver des informations propres à la machine source, notamment son SID ou d’autres éléments d’identité.
Historiquement, certains scénarios continuaient à fonctionner malgré tout. Ce n’était pas propre, mais en apparence, ça passait.
Avec les derniers durcissements, Windows rattache davantage l’authentification à l’identité réelle de la machine. Le mécanisme de détection du loopback utilise maintenant une identité machine qui combine des éléments liés au démarrage courant et des éléments persistants entre les redémarrages. Cela permet de mieux détecter les tickets ou artefacts d’authentification incohérents.
Le résultat est logique : si deux machines se ressemblent trop parce qu’elles ont été clonées sans préparation correcte, Windows peut considérer que l’authentification n’est pas fiable.
Les symptômes possibles
En exploitation, le sujet peut apparaître sous plusieurs formes :
- connexion RDP qui échoue ;
- accès SMB ou Admin$ impossible ;
- partages réseau inaccessibles ;
- authentification NTLM ou Kerberos qui ne passe plus ;
- erreurs d’accès refusé ;
- prompt d’identifiants en boucle ;
- comportement étrange entre deux machines pourtant “valides”.
Le signal à surveiller est l’événement LsaSrv Event ID 6167 dans le journal System de la machine cible.
Le message indique notamment :
There is a partial mismatch in the machine ID.This indicates that the ticket has either been manipulatedor it belongs to a different boot session.
Microsoft indique clairement que cet événement est attendu dans les scénarios concernés : il signale que Windows bloque une authentification jugée incohérente avec l’identité machine.
Le vrai sujet : les images et les clones
La recommandation Microsoft reste la même depuis des années : si l’on déploie Windows par image ou duplication, il faut exécuter Sysprep avant la capture.
Sysprep supprime les informations spécifiques à la machine, dont le SID, afin que chaque machine déployée génère sa propre identité. Microsoft rappelle aussi qu’exécuter Sysprep après coup, sur une image déjà clonée et déployée, ne remet pas l’environnement en conformité. Sysprep doit être exécuté avant la capture de l’image.
C’est là que le changement devient très concret.
Une vieille pratique de clonage qui “fonctionnait” encore peut maintenant se transformer en incident visible après patching. Et dans ce cas, le problème n’est pas la mise à jour Windows. Le problème est que l’environnement reposait sur une méthode de déploiement non supportée.
La mauvaise réponse : chercher uniquement un contournement
Microsoft évoque bien un mécanisme temporaire de compatibilité, accessible via le support Microsoft, mais il est explicitement présenté comme non recommandé et temporaire. Il réduit les protections de sécurité introduites par les dernières mises à jour et ne doit servir qu’à gagner du temps pendant une remédiation. Le rollback temporaire est indiqué comme disponible jusqu’à fin 2027.
Ce point est important.
Le contournement ne doit pas devenir une stratégie d’exploitation. S’il est utilisé, il faut l’accompagner d’un plan clair : identifier les machines concernées, reconstruire proprement, supprimer les clones problématiques, puis retirer le contournement.
Sinon, on revient exactement au point de départ : une dette technique masquée par une clé de registre.
Ce qu’il faut faire côté IT
La bonne approche est assez simple, mais elle demande de la rigueur.
D’abord, identifier les environnements à risque : templates VM anciens, images créées manuellement, clones de serveurs, postes reconditionnés, masters historiques, machines déployées hors processus officiel.
Ensuite, rechercher les symptômes : échecs RDP, SMB, Admin$, NTLM, Kerberos, et surtout l’Event ID 6167 côté machine cible.
Puis, traiter la cause : reconstruire les machines concernées avec une méthode supportée, en utilisant Sysprep avant capture ou un processus moderne de déploiement.
Sur les postes de travail, cela pousse aussi à revoir les pratiques : Autopilot, Intune, provisioning propre, ou image maîtrisée avec Sysprep lorsque l’image reste nécessaire.
Sur les serveurs, le sujet est encore plus sensible. Un template Windows Server mal généralisé peut fonctionner des mois, jusqu’au moment où une mise à jour de sécurité révèle le problème.
Ma lecture
Ce changement va probablement déranger certains environnements.
Pas parce que Microsoft casse volontairement quelque chose, mais parce que Windows arrête de tolérer silencieusement certains clones mal préparés.
C’est exactement le genre de sujet qui tombe entre deux équipes : sécurité, poste de travail, infra, virtualisation, exploitation. Pourtant, la cause est souvent très basique : une image ou un template qui n’a jamais été correctement généralisé.
Le message à retenir est simple : si une machine Windows est dupliquée, elle doit passer par un processus supporté.
Sinon, tôt ou tard, l’identité machine finit par poser problème.
Et avec ces nouveaux durcissements, ce “tôt ou tard” risque d’arriver plus vite que prévu.
Conclusion
Le durcissement des actions administratives Windows n’est pas seulement une nouveauté de sécurité. C’est aussi un rappel brutal des bonnes pratiques de déploiement.
Les machines clonées sans Sysprep peuvent désormais rencontrer des échecs Kerberos, NTLM, RDP ou SMB. L’événement LsaSrv 6167 est le signal à surveiller. Le contournement existe, mais il est temporaire et affaiblit la sécurité.
La vraie correction reste la même : arrêter les clones non supportés, reconstruire proprement les machines concernées, et remettre les processus d’imaging sous contrôle.