Pourquoi un portable de domaine accepte l'ancien mot de passe hors ligne

Un changement de mot de passe arrive partout à la fois, sauf sur le seul portable resté une semaine hors ligne. Le webmail accepte le nouveau mot de passe, un poste de bureau au bureau l'accepte aussi, et la machine distante se connecte toujours avec l'ancien lorsque le VPN est coupé. Ce n'est pas un second mot de passe ni un bug de synchronisation de l'annuaire. C'est le vérificateur d'ouverture de session mis en cache qui fait ce pour quoi il a été conçu, et la solution est une séquence, pas une réinitialisation.

Le portable vérifie un vérificateur mis en cache

Windows joint à un domaine conserve un vérificateur local pour les ouvertures de session interactives récentes réussies, afin que la machine puisse démarrer quand aucun contrôleur de domaine ne répond. Ce vérificateur est dérivé du mot de passe tel qu'il était lors de cette ouverture de session. Changer le mot de passe ailleurs met à jour l'annuaire, pas la copie sur un portable qui ne lui a pas parlé depuis.

L'ancien mot de passe peut donc encore ouvrir la session locale tout en étant invalide pour toute nouvelle authentification de domaine. Ce sont deux observations différentes, et les confondre mène à des réinitialisations répétées.

Confirmez quelle information d'identification est réellement utilisée avant de changer quoi que ce soit d'autre. Un PIN Windows Hello, une connexion Entra ID et un mot de passe de domaine classique sont des mécanismes distincts, et le PIN en particulier n'est pas le mot de passe du domaine même quand il déverrouille le même bureau.

L'authentification réseau n'est pas une ouverture de session interactive

Ouvrir un partage de fichiers avec le nouveau mot de passe prouve que le chemin réseau fonctionne. Cela ne rafraîchit pas le cache de l'ouverture de session interactive, car Windows traite l'authentification réseau et l'authentification interactive comme des opérations distinctes avec un état distinct.

Le vérificateur n'est rafraîchi que lorsqu'une ouverture de session interactive contacte réellement un contrôleur de domaine ; un lecteur mappé ou une invite Outlook ne le fait pas.

Cette distinction explique le rapport habituel : l'utilisateur peut lire son courrier et ouvrir l'intranet, mais l'écran de verrouillage demande encore l'ancien mot de passe. Elle explique aussi pourquoi un VPN démarré après l'ouverture de session ne peut pas aider la connexion initiale, puisque le tunnel arrive après que la décision a déjà été prise localement.

Obtenez une ouverture de session en ligne au bon moment

Le cache est rafraîchi lorsque l'utilisateur ouvre une session de façon interactive alors que le domaine est joignable. Pour une machine distante, cela signifie que le tunnel doit exister avant l'évaluation de l'information d'identification, pas après l'apparition du bureau.

Vérifiez si le déploiement prend en charge la connectivité avant ouverture de session ou un tunnel d'appareil. Ils sont conçus pour ce moment précis, et un tunnel utilisateur ne les remplace pas :

nltest /dsgetdc:corp.example
klist

Si le point de terminaison n'a pas de chemin avant ouverture de session, utilisez le processus de récupération pris en charge que l'organisation documente. Certains environnements utilisent une séquence connexion, verrouillage et déverrouillage avec le tunnel maintenu ouvert sur l'écran de verrouillage ; d'autres envoient l'appareil vers une étape de récupération gérée. Suivez celle qui correspond au client et, avant de compter dessus, confirmez que le tunnel survit à l'écran de verrouillage.

Protégez le chemin du retour

Avant de fermer la session d'une machine distante, décidez comment la prochaine ouverture de session atteindra le domaine. Un tunnel utilisateur qui tombe avec la session peut supprimer le seul chemin sur lequel vous comptiez, et alors ni l'ancien ni le nouveau mot de passe ne vous fera passer l'écran de verrouillage. Gardez un compte administrateur local ou une console hors bande comme solution de repli. Notez l'étape de récupération là où l'utilisateur peut la atteindre sans se connecter.

Pour le support, recueillez quatre faits : où le mot de passe a changé, quelle information d'identification fonctionne encore hors ligne, si un contrôleur de domaine est joignable par le tunnel et quelle méthode d'ouverture de session le portable utilise.

Ces quatre séparent un vérificateur obsolète d'un verrouillage de compte ou d'une ouverture de session VPN refusée, qui se ressemblent dans un ticket et ont des correctifs différents. Un compte verrouillé rejettera aussi le nouveau mot de passe en ligne, alors testez-le avant d'accuser le cache.

Bouclez la boucle avec une ouverture de session en ligne

L'objectif est une ouverture de session interactive prise en charge pendant que le domaine est joignable, suivie d'un état hors ligne connu. Cet événement unique rafraîchit le vérificateur et met fin au cycle de changement du mot de passe sur chaque appareil.

Vérifiez ensuite l'état avec le nombre d'ouvertures de session en cache et une recherche de contrôleur de domaine :

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v CachedLogonsCount
nltest /sc_verify:corp.example

Si le nombre est zéro, l'ouverture de session mise en cache est désactivée par stratégie et le comportement hors ligne ne changera pas, quel que soit le nombre de réinitialisations du mot de passe. C'est une décision de stratégie à soulever auprès du propriétaire, pas un contournement à appliquer localement.