Windows : réparer une relation d’approbation AD sans sortir le poste du domaine

Réparer le canal sécurisé, pas réinstaller le poste

Une erreur de relation d’approbation peut empêcher une connexion au domaine alors que le poste démarre normalement. Une réparation ciblée du canal sécurisé peut éviter une sortie et une réintégration au domaine, mais seulement après avoir confirmé la cause.

Ce guide concerne un poste Windows ou serveur membre AD DS. Il ne répare ni une relation d’approbation entre domaines, ni une inscription Microsoft Entra. Les contrôleurs de domaine exigent une procédure distincte.

Comprendre ce qui peut diverger

Le poste et Active Directory maintiennent un secret associé au compte machine. Une restauration, un clonage incorrect ou une incohérence AD peuvent rompre cette relation. Un long séjour hors ligne ne suffit pas, à lui seul, à prouver que le secret a expiré.

Microsoft distingue notamment le poste qui possède un secret plus ancien et AD qui possède une valeur plus ancienne. Dans le second cas, vérifier réplication et restauration côté annuaire avant de réparer les clients. Des incidents simultanés sur plusieurs machines justifient une investigation AD.

• Microsoft Learn ↗

Préparer l’accès de récupération

Avant un changement, confirmer un accès administrateur local fonctionnel, une console ou un accès hors bande, et la procédure BitLocker applicable. Un mot de passe LAPS doit être récupérable par une personne autorisée; ne pas le copier dans le journal d’intervention.

Utiliser Windows PowerShell 5.1 élevé pour les exemples. Le test nécessite les droits administratifs locaux. La réparation nécessite aussi une identité AD autorisée à réinitialiser le mot de passe du compte ordinateur ciblé. Faire déléguer ce droit sur le périmètre nécessaire plutôt que donner Domain Admin.

Prévoir un poste pilote, une fenêtre si un serveur héberge des services, une sauvegarde adaptée et un responsable. Ne pas compter uniquement sur une session distante qui pourrait être perdue. Aucun abonnement Entra supplémentaire n’est requis pour ces commandes AD DS; les exigences de licence Windows habituelles demeurent.

• Microsoft Learn ↗

Étape 1 : confirmer le rôle et les symptômes

Lire le rôle avant de poursuivre. DomainRole 4 ou 5 correspond à un contrôleur de domaine : arrêter cette procédure. Un poste hors domaine n’a pas de canal AD DS à réparer.

Relever le message exact et les événements System/NETLOGON autour de l’échec. L’événement 3210 est une piste documentée, pas une raison de réinitialiser toutes les machines. Protéger les noms internes présents dans les sorties.

# Read-only, on the affected device
Get-CimInstance Win32_ComputerSystem |
  Select-Object Name,Domain,PartOfDomain,DomainRole
Get-WinEvent -FilterHashtable @{
  LogName='System'; ProviderName='NETLOGON'
  StartTime=(Get-Date).AddHours(-4)
} -ErrorAction Stop | Select-Object TimeCreated,Id,Message

Étape 2 : vérifier DNS, réseau et heure

Le poste doit utiliser des résolveurs capables de résoudre les zones AD et joindre un DC approprié. Une réponse DNS ou un port TCP accessible ne prouve pas que tous les flux AD fonctionnent. Vérifier aussi VPN, routage et règles réseau selon l’architecture.

Lire l’état horaire et la source de synchronisation avant toute correction. Une erreur Kerberos liée à l’heure ne se corrige pas en réinitialisant automatiquement le compte machine. Les commandes ci-dessous sont diagnostiques; remplacer le domaine fictif.

# Read-only; fictional domain
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName -Type SRV '_ldap._tcp.dc._msdcs.contoso.com'
nltest /dsgetdc:contoso.com
w32tm /query /status
w32tm /query /source

Étape 3 : tester sans réparer

Choisir un DC dont la santé et la réplication sont confirmées. Test-ComputerSecureChannel sans -Repair vérifie le canal du poste local. True signifie que ce test réussit; cela ne valide pas toutes les applications ou stratégies. False nécessite une analyse des prérequis et des erreurs.

Ne pas exécuter ce test sur un DC : Microsoft documente des résultats d’erreur trompeurs dans ce cas. Si le compte ordinateur a été supprimé, désactivé ou recréé, faire examiner son identité et son historique avant une réparation.

# Read-only; member computer only
$dc = 'DC01.contoso.com'
Test-ComputerSecureChannel -Server $dc -Verbose

• Microsoft Learn ↗

Étape 4 : réparation pilote explicitement autorisée

Changement : après diagnostic et autorisation de la fenêtre, exécuter une seule réparation sur le membre concerné. Get-Credential évite de placer un secret en clair dans le script. Utiliser le compte délégué approprié, puis retirer la variable de session.

Ne pas enchaîner automatiquement plusieurs outils de réinitialisation. Si la commande échoue, conserver le message et vérifier droits, DC choisi et connectivité. Si elle réussit, passer aux validations et prévoir un redémarrage contrôlé selon la procédure applicable; ne pas forcer un redémarrage à distance sans préparation.

# CHANGE: one approved member computer only
$credential = Get-Credential -Message 'Authorized AD computer-account repair'
try {
  Test-ComputerSecureChannel -Repair -Server 'DC01.contoso.com' `
    -Credential $credential -Verbose -ErrorAction Stop
} finally {
  Remove-Variable credential -ErrorAction SilentlyContinue
}

• Microsoft Learn ↗

Validation et scénario concret

Exemple fictif : PC-COMPTA01 échoue après une restauration. DNS et heure sont corrects, le compte AD existe et les DC sont cohérents. Le test échoue, puis la réparation pilote réussit. Après redémarrage planifié, valider une connexion au domaine avec un utilisateur de test autorisé et l’accès à une ressource interne.

Refaire le test sans -Repair, contrôler les événements et vérifier les fonctions attendues : GPO, partage et application métier. Une connexion avec des identifiants en cache ne prouve pas à elle seule une authentification auprès du DC. Documenter les résultats avant/après et surveiller la récidive.

Récupération et cas où arrêter

La réparation modifie un secret : il n’existe pas de simple bouton Annuler. Une restauration aveugle d’un ancien instantané peut réintroduire le décalage. Le plan de récupération repose sur l’accès local, la console, la sauvegarde et une procédure coordonnée avec l’équipe AD.

Arrêter si le poste est un DC, si plusieurs DC divergent, si l’objet ordinateur est douteux, si un doublon de nom est suspecté ou si une compromission est possible. Une réintégration au domaine peut devenir nécessaire dans certains cas, mais doit être préparée avec profils, certificats et dépendances; elle ne constitue pas le premier réflexe.

Ne pas désactiver la rotation des mots de passe machine ni affaiblir Netlogon pour masquer la panne. Pour un incident récurrent, un diagnostic Active Directory permet d’examiner les dépendances et la cause; ce guide ciblé ne remplace pas un audit complet.

• Microsoft Learn ↗