Confiance de domaine rompue après un mois hors ligne ? Vérifiez d’abord

Un portable reste six semaines hors du VPN, revient, et l’utilisateur ne peut pas se connecter avec un compte de domaine. L’erreur mentionne une relation d’approbation, alors quelqu’un réinitialise le compte d’ordinateur, ou force l’utilisateur sur le tunnel complet, et le problème semble disparaître. Aucune des deux actions n’a prouvé ce qui était cassé. Un membre Windows peut rester hors ligne bien au-delà de l’intervalle habituel de mot de passe machine sans perdre automatiquement l’approbation, le premier travail est donc de séparer une panne d’accessibilité d’une véritable divergence de secret.

L’erreur ressemble à un problème d’approbation, mais trois états se ressemblent

Un utilisateur peut se connecter avec des informations de domaine en cache, le poste peut ne pas trouver de contrôleur de domaine, ou le membre et le domaine peuvent réellement être en désaccord sur le compte d’ordinateur. Seul le troisième est une relation d’approbation rompue au sens strict.

L’état de la réplication AD est une quatrième observation, et elle ne concerne pas du tout ce poste. Elle décrit l’accord entre contrôleurs de domaine, et un tableau de bord de réplication sain ne prouve pas que le secret local de cette machine correspond à son compte d’ordinateur.

Le fameux délai par défaut de 30 jours est une politique de changement, pas une échéance d’expiration hors ligne. L’explication de Microsoft sur le mot de passe du compte machine décrit un processus de changement coordonné, et une organisation peut configurer un autre intervalle.

Une icône VPN ne prouve rien sur le canal sécurisé

La connectivité doit être suffisante pour atteindre les services de domaine avant qu’un test ait un sens. Cela suppose le résolveur DNS de domaine prévu, un contrôleur localisable, des services d’authentification joignables et une horloge assez proche pour Kerberos.

Le tunnel complet peut être une conception parfaitement valable ici. Passer au tunnel divisé n’est pas un prérequis pour une relation de domaine saine, et le traiter comme tel transforme un diagnostic en changement d’architecture. Vérifiez quel contrôleur le poste choisit réellement, et conservez ce nom avec l’erreur.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Notez le serveur DNS, le contrôleur résolu et le texte exact de l’erreur. Un client VPN qui se dit connecté vous dit que le tunnel existe, pas que le chemin vers le domaine fonctionne. Un contrôleur qui répond sur le port Kerberos mais pas sur le port d’annuaire est une constatation de pare-feu, pas une constatation d’approbation.

Testez le membre avant de le réparer

Sur un membre de domaine Windows autorisé, Test-ComputerSecureChannel -Verbose est un contrôle en lecture seule du canal entre la machine et le domaine. Exécutez-le dans le contexte de la machine que vous examinez, pas depuis un contrôleur de domaine, qui a un autre rôle et d’autres règles de récupération. Consignez la sortie et le code de retour plutôt que le mot réussi ou échoué. Si l’applet est absente de cette version, le module est un problème distinct.

Le résultat a encore besoin de contexte. Si la machine ne peut pas atteindre ou s’authentifier auprès du contrôleur choisi, un test échoué n’est pas une preuve indépendante qu’un mot de passe hors ligne a expiré. Conservez l’erreur réelle et le contrôleur utilisé, et répétez le test une fois le chemin reconnu bon.

Corrélez les événements Netlogon sur le membre et sur le contrôleur concerné autour de l’incident. Conservez le nom de la machine, l’adresse source, l’heure et toute preuve de changement de compte. La connexion réussie d’un autre utilisateur, ou un tableau de bord de contrôleur sain, ne peuvent pas remplacer l’échange de cette machine.

Ne réparez que la relation que vous avez prouvée

Une fois la connectivité stable et un administrateur ayant confirmé qu’une réparation est appropriée, le mode -Repair de l’applet avec des identifiants autorisés est une opération prise en charge pour un poste membre. Il modifie la relation, et ce n’est pas un autre test en lecture seule.

Gardez un compte de récupération local approuvé et un chemin d’administration disponibles avant le changement. Les contrôleurs de domaine ont un rôle de récupération différent et ne doivent pas être traités comme des postes ordinaires par cette procédure. Utilisez le processus de récupération de l’organisation au lieu d’enchaîner plusieurs outils de réinitialisation en espérant que l’un d’eux soit le bon.

Après la réparation, vérifiez un nouveau test du canal sécurisé et l’opération de domaine d’origine. Préservez les profils utilisateur et l’état des applications, et ne faites pas de la suppression-réintégration la première action inexpliquée.

Que vérifier lorsque la panne revient

Si la panne revient, examinez le retour en arrière, l’identité en double et le moment des changements de compte plutôt que de réinitialiser à nouveau le même compte. Une image restaurée, un instantané, une identité de machine clonée ou une réinitialisation de compte d’ordinateur effectuée ailleurs méritent tous une enquête.

Une réinitialisation réussie temporaire est une preuve de récupération utile, mais elle ne prouve pas qu’un VPN intermittent a causé la divergence d’origine. L’occurrence suivante est celle qui vous dira si la cause a jamais été éliminée.

Écrivez le contrôleur, le serveur DNS et la sortie du test dans le ticket. C’est ce dossier qui distingue une véritable panne d’approbation d’un portable qui n’a simplement pas pu trouver le domaine.