Erreur « The trust relationship between this workstation and the primary domain failed » : causes, correctifs PowerShell et GPO pour Windows 10 et Windows Server

Vous voyez « The trust relationship between this workstation and the primary domain failed » sur des postes Windows 10 reliés à des contrôleurs Windows Server ? Voici un guide opérationnel côté serveur et des scripts éprouvés pour réparer, stabiliser et prévenir durablement ces ruptures de confiance.

Sommaire

Vue d’ensemble du problème

Dans un environnement Active Directory (par exemple DC Windows Server 2019 avec des clients Windows 10 et quelques serveurs 2012), l’ouverture de session échoue avec le message : « The trust relationship between this workstation and the primary domain failed ». La sortie/entrée du domaine peut masquer temporairement le problème, mais certains postes rechutent, parfois juste après un changement de mot de passe utilisateur. La cause réelle est rarement le compte utilisateur : c’est presque toujours le canal sécurisé Netlogon du poste qui est rompu, car le mot de passe du compte machine n’est plus synchronisé avec le domaine.

Symptômes typiques

Échec de logon domaine sur un poste alors que d’autres postes fonctionnent.
Événements Netlogon 5722/5805 côté DC, 3210/5719 côté client.
Le test Test-ComputerSecureChannel retourne False.
Le problème peut réapparaître après redémarrage, restauration d’un cliché, ou sur des sites distants avec latence et réplication irrégulière.

Pourquoi l’erreur survient

Le poste membre échange en permanence avec un DC via le canal sécurisé Netlogon. Ce canal repose sur un mot de passe de compte machine qui tourne automatiquement (par défaut tous les 30 jours). Si le mot de passe local et celui stocké dans l’objet ordinateur AD divergent, l’authentification échoue :

Désynchronisation du mot de passe machine : restauration d’un poste/VM à un état antérieur, réinitialisation du compte dans AD sans opération côté poste, clonage d’image sans Sysprep, etc.
Réplication AD en retard : le poste répare contre DC‑A mais s’authentifie ensuite contre DC‑B qui n’a pas reçu la mise à jour.
Mauvaise configuration DNS : clients pointant vers un DNS non‑AD ou mixant DNS public/routeur et DNS AD.
Désynchronisation de l’heure (Kerberos) : écart d’horloge, PDC non fiable ou NTP mal configuré.
Postes restés hors ligne longtemps ou réseau instable pouvant révéler un mot de passe machine déjà obsolète suite à une restauration.
Snapshots/VM : retour à un cliché antérieur d’un poste joint au domaine.
Images non sysprepées ou SID dupliqués.

Ce que le changement de mot de passe utilisateur n’explique pas

Le changement de mot de passe utilisateur n’altère pas le canal sécurisé du poste. S’il y a coïncidence temporelle, c’est le redémarrage ou le délai qui remet en lumière un canal déjà rompu.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Correction immédiate
Message de rupture de confiance	Canal Netlogon rompu (mot de passe machine désynchronisé)	`Test-ComputerSecureChannel` → False	Réparer avec `-Repair` ou `nltest /sc_reset`
Poste réparé sur DC‑A, rechute ailleurs	Réplication AD en retard	`repadmin /replsummary`, `dcdiag`	Corriger réplication avant réparations massives
Problème sur un site distant	DNS non‑AD ou site/subnet AD non mappé	`ipconfig /all`, `nltest /dsgetdc:DOMAINE`	DNS AD uniquement, configurer Sites et Services AD
Restauration de VM/instantané	Password machine revenu à un ancien état	Historique snapshots / gestion VM	`Reset-ComputerMachinePassword` puis redémarrage
Échecs intermittents	Heure instable, NTP du PDC mal réglé	`w32tm /query /status`	Refixer la hiérarchie NTP, resynchroniser

Résolutions immédiates sur un poste

Procédez du moins intrusif au plus intrusif. Dans tous les cas, utilisez un compte local ou un compte admin encore valable sur le poste.

Réparer le canal sécurisé sans sortir du domaine (recommandé)

PowerShell

# Vérifier l’état
Test-ComputerSecureChannel

# Réparer (invite d’identifiants)

Test-ComputerSecureChannel -Repair -Credential DOMAINE\Admin

# Variante : cibler un DC précis et réinitialiser le mot de passe machine

Reset-ComputerMachinePassword -Server DC01 -Credential DOMAINE\Admin

# Redémarrer ensuite

Restart-Computer

Invite de commandes

nltest /sc_reset:DOMAINE.local
shutdown /r /t 0

Ces commandes ne retirent pas le poste du domaine et conservent profils, droits locaux, etc. Elles suffisent dans la majorité des cas.

Réinitialiser le compte ordinateur dans AD puis réparer côté client

Dans Utilisateurs et ordinateurs Active Directory : clic droit sur l’objet ordinateur → Réinitialiser le compte. Important : cette action doit être suivie d’une réparation côté poste (PowerShell/nltest) ou d’une sortie/entrée du domaine. La réinitialisation côté AD seule n’est pas suffisante.

Sortir puis réintégrer le domaine (option plus intrusive)

Joindre un groupe de travail, redémarrer.
Rejoindre le domaine avec des DNS AD valides et des identifiants d’admin du domaine.

# Exemple PowerShell
Add-Computer -DomainName DOMAINE.local -Credential DOMAINE\Admin -Restart

À réserver aux cas où la réparation échoue ou si l’image/snapshot a introduit d’autres incohérences.

Contrôles d’infrastructure côté serveur

DNS : fondation critique

Les clients et serveurs membres doivent pointer uniquement vers des DNS AD (vos DC) ; pas de DNS de box/routeur ni de DNS public sur les cartes réseau.
Sur les DC, configurez des redirecteurs sortants au lieu de mettre des DNS publics sur l’interface réseau.
Vérifiez que le suffixe de recherche et les enregistrements SRV sont résolus par les clients du site.

Heure et Kerberos

Le PDC Emulator du domaine doit être la source NTP de référence. Les autres DC se synchronisent sur lui, et les membres sur les DC.
Écart d’horloge recommandé : < 5 minutes.

# Sur le PDC Emulator (exemple)
w32tm /query /status
w32tm /config /manualpeerlist:"serveurs-ntp-externe,0x9" /syncfromflags:manual /reliable:yes /update
net stop w32time & net start w32time
w32tm /resync /force

# Sur un membre

w32tm /query /status

Santé et réplication AD

dcdiag /v
repadmin /replsummary
repadmin /showrepl *

Résolvez toute erreur de réplication avant de lancer une campagne de réparation de masse. Sinon, les corrections seront incohérentes d’un DC à l’autre.

Sites et Services AD

Mappez chaque sous-réseau IP à un site AD pour éviter que des clients d’un site distant s’authentifient sur un DC éloigné.
Vérifiez nltest /dsgetdc:DOMAINE depuis un poste du site : il doit découvrir un DC local.

Pare-feu et ports requis

Service	Ports/Protocoles	Rôle	Remarques
Kerberos	88/TCP, 88/UDP	Authentification	Échec si l’heure dérive
LDAP / LDAPS	389/TCP/UDP, 636/TCP	Annuaire	LDAPS si TLS/PKI
DNS	53/TCP/UDP	Résolution	Doit viser vos DC
SMB	445/TCP	Accès SYSVOL/NETLOGON	GPO et scripts
RPC Endpoint Mapper	135/TCP	Appels RPC	Netlogon via RPC
RPC dynamiques	49152–65535/TCP	RPC divers	Plage par défaut depuis 2008+

Prévention durable via stratégies et bonnes pratiques

Rotation du mot de passe machine contrôlée par GPO

GPO : Configuration ordinateur → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Options de sécurité

Domain member: Disable machine account password changes : Désactivé (ne jamais l’activer en production).
Domain member: Maximum machine account password age : 30 jours (par défaut). Adapter à 60–90 jours si vous avez beaucoup de portables hors réseau, en acceptant l’impact sécurité.

Vérifiez qu’aucune GPO ni paramètre Registre n’a figé la rotation :

# À auditer sur un échantillon
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
  | Select-Object DisablePasswordChange, MaximumPasswordAge

DNS cohérent par DHCP/GPO

Distribuez uniquement les adresses de vos DNS AD en option 006 DHCP.
Empêchez via GPO toute configuration manuelle de DNS non‑AD sur les cartes réseau gérées.

Surveillance continue

Sur les DC : surveillez les événements Netlogon 5722 et 5805 (échecs de canal).
Sur les clients : événements 3210 et 5719.
Alimentez un tableau de bord : volume d’échecs par site, par sous-réseau, par contrôleur.

Automatisation et remédiation à grande échelle

Campagne PowerShell distante

Déployez via Intune, ConfigMgr, PDQ ou outils équivalents. Stratégie : tester, réparer si nécessaire, redémarrer.

$cred = Get-Credential 'DOMAINE\Admin'
$computers = Get-Content '.\machines.txt'

foreach (\$c in \$computers) {
Write-Host "==> \$c"
try {
Invoke-Command -ComputerName \$c -ScriptBlock {
param(\$cred)
\$ok = Test-ComputerSecureChannel
if (-not \$ok) {
Test-ComputerSecureChannel -Repair -Credential \$cred | Out-Null
"REPAIRED"
Register-ScheduledTask -TaskName "RebootOnce" -RunLevel Highest -Action (New-ScheduledTaskAction -Execute "shutdown.exe" -Argument "/r /t 5") -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1)) -Force | Out-Null
} else {
"OK"
}
} -ArgumentList \$cred -ErrorAction Stop
} catch {
Write-Warning "INJOIGNABLE: \$c — \$($\_.Exception.Message)"
}
}

Astuce : pour les machines injoignables, poussez une tâche planifiée au démarrage par GPO ; elle exécutera la réparation dès que le poste se rallumera.

Script de démarrage robuste (GPO)

@echo off
REM Script de démarrage : vérifie et répare le canal sécurisé si besoin
powershell -NoProfile -ExecutionPolicy Bypass -Command ^
  "$domain = (Get-ADDomain).DNSRoot; ^
   if (-not (Test-ComputerSecureChannel)) { ^
     $cred = Get-Credential 'DOMAINE\Admin'; ^
     Test-ComputerSecureChannel -Repair -Credential $cred | Out-Null; ^
     Restart-Computer -Force ^
   }"

Remplacez DOMAINE\Admin par un compte de service dédié aux opérations de maintenance et stockez ses secrets de manière sécurisée (CSP, coffre-fort d’identifiants, variables protégées de votre outil de déploiement).

Vérification post‑remédiation

nltest /sc_verify:DOMAINE.local
# ou
Test-ComputerSecureChannel

Loggez le résultat ; exigez 100 % de conformité avant de clôturer l’incident.

Erreurs fréquentes à éviter

Désactiver la rotation du mot de passe machine pour « stabiliser » : cela masque le problème et augmente l’exposition.
Réinitialiser l’objet ordinateur dans AD puis ne rien faire côté poste : la rupture persiste.
Réparer en masse sans corriger DNS et réplication : les postes se re‑casseront au prochain contact avec un autre DC.
Utiliser des DNS externes sur les clients/DC : source de découvertes DC erronées et d’échecs Kerberos.
Restaurer des clichés de VMs jointes au domaine sans procédure : la désynchronisation est quasi garantie.

Notes avancées pour environnements virtualisés

Évitez de revenir à des snapshots de postes membres. Si vous devez le faire (lab, tests), planifiez automatiquement un Reset-ComputerMachinePassword au premier démarrage.
Ne revert jamais un contrôleur de domaine à un instantané passé ; risque d’USN rollback et corruption de l’annuaire.
Pour le clonage d’images, exécutez Sysprep et laissez le specialize générer un SID et un compte machine propres.

Jeu de commandes utiles

# Sur un client
ipconfig /all
nltest /dsgetdc:DOMAINE.local
nltest /sc_query:DOMAINE.local
nltest /sc_verify:DOMAINE.local
klist
w32tm /query /status

# Sur un DC

dcdiag /v
repadmin /replsummary
repadmin /showrepl \*
Get-ADComputer -Filter \* -Properties PasswordLastSet |
Where-Object { $\_.PasswordLastSet -lt (Get-Date).AddDays(-60) } |
Select-Object Name, PasswordLastSet

Plan d’action recommandé

Stabiliser l’infrastructure : DNS AD uniquement, hiérarchie NTP claire, réplication saine, sites/subnets bien mappés.
Réparer sans déjoindre autant que possible : Test-ComputerSecureChannel -Repair ou nltest /sc_reset.
Réinitialiser l’objet ordinateur dans AD seulement si nécessaire, suivi d’une action côté client.
Remédiation de masse : script distant + redémarrage contrôlé, puis vérification nltest /sc_verify.
Prévenir : GPO de rotation du mot de passe machine active, DNS cohérent via DHCP/GPO, surveillance des événements clés.

FAQ express

Changer le mot de passe utilisateur cause‑t‑il l’erreur ? Non. La coïncidence temporelle peut tromper, mais la panne concerne le mot de passe machine et le canal Netlogon.

Combien de temps un poste peut‑il rester hors réseau ? La rotation se fait côté poste ; un long hors‑réseau n’est pas fatal en soi. La rupture provient surtout d’états restaurés/clonés ou d’incohérences de réplication.

Faut‑il déjoindre/rejoindre systématiquement ? Non. La réparation du canal sécurisé suffit presque toujours et évite la perte de caches/liaisons locales.

Conclusion

La clé d’une correction durable côté serveur n’est pas un script miracle isolé : c’est un trio DNS propre, temps fiable et réplication saine, complété par des GPO qui laissent la rotation des mots de passe machines fonctionner comme prévu. Une fois l’infrastructure stabilisée, la réparation non intrusive du canal sécurisé (-Repair/nltest) et l’automatisation de la remédiation ramènent rapidement l’environnement à l’équilibre — et l’y maintiennent.

Erreur « The trust relationship between this workstation and the primary domain failed » : causes, correctifs PowerShell et GPO pour Windows 10 et Windows Server