Après la restauration d’un contrôleur de domaine très ancien, les postes refusent l’authentification (« perte de confiance »). Ce guide explique pourquoi cela arrive et fournit une procédure fiable, outillée et industrialisable pour rétablir rapidement l’environnement.
Sommaire
Vue d’ensemble
Scénario typique : l’unique DC du domaine tombe en panne. On restaure une sauvegarde vieille d’environ 5 mois. Résultat : les serveurs et postes ne « font plus confiance » au domaine, l’ouverture de session échoue et les tentatives de Test-ComputerSecureChannel -Repair ou netdom ne tiennent pas dans le temps.
La cause première est la divergence des mots de passe des comptes machine (renouvelés automatiquement côté clients tous les ~30 jours) par rapport à ceux stockés dans l’AD restauré. À cela s’ajoutent parfois une horloge hors tolérance Kerberos, un DNS mal configuré ou un partage SYSVOL indisponible.
Pourquoi la relation d’approbation se casse
- Rotation du mot de passe de compte machine : par défaut, chaque membre du domaine change son mot de passe machine environ tous les 30 jours. Avec un DC restauré à J‑159, l’AD « connaît » un ancien secret que la machine a changé plusieurs fois depuis. Le canal sécurisé (secure channel) ne s’établit plus.
- Kerberos et l’heure : Kerberos tolère un faible écart d’horloge. Un PDC Emulator mal synchronisé suffit à faire échouer tickets TGT/TGS et à mimer une « perte de confiance ».
- DNS interne : si les clients interrogent un DNS public ou un DNS tiers, ils ne résolvent pas les enregistrements SRV du domaine. Les jonctions/renouvellements du canal sécurisé échouent.
- SYSVOL/NETLOGON : si les partages ne sont pas publiés (DFSR/FRS bloqué après restauration), les scripts d’ouverture de session et GPO ne s’appliquent pas, aggravant les symptômes.
Symptômes fréquents & lectures d’événements
| Symptôme | Cause probable | Journaux/événements à vérifier | Remède court |
|---|---|---|---|
| « La relation d’approbation… a échoué » lors de l’ouverture de session | Secret machine désynchronisé | System : Netlogon 3210/5722, Security : 4625, KDC/Kerberos | Réparer canal sécurisé depuis la machine, vérifier heure/DNS |
| « Le domaine spécifié n’existe pas ou n’a pas pu être contacté » | DNS non pointé sur le DC | DNS Server/ClientDNS, dcdiag /test:DNS | Pointer DNS vers l’IP du DC, purger cache |
| GPO inapplicables, scripts absents | SYSVOL/NETLOGON non partagés | DFSR : 2213/4614, Netlogon : 5719 | Corriger DFSR/FRS, restaurer SYSVOL, relancer Netlogon |
Erreurs KRB_AP_ERR_MODIFIED | Écart d’horloge / SPN / secret | System : Time‑Service, KDC | Resynchroniser le temps, vérifier SPN |
Checklist de remise en état — ordre recommandé
1) Valider la santé du DC restauré
- Services : AD DS, DNS, DFS Replication (ou FRS selon ancienneté) doivent être Running.
- Partages :
net sharedoit listerSYSVOLetNETLOGON. - Rôles FSMO : vérifier où ils résident (
netdom query fsmo) et que le PDC Emulator est ce DC. - DNS AD‑intégré :
dcdiag /test:DNSdoit passer, sans erreur SRV/Ns/Glue. - Horloge (sur le PDC Emulator) :
w32tm /config /manualpeerlist:"ntp.exemple.tld" /syncfromflags:manual /reliable:yes /update w32tm /resync /nowait w32tm /query /status w32tm /query /peers - Enregistrements SRV du DC : relancer Netlogon pour réenregistrer :
net stop netlogon & net start netlogon nltest /dsregdns
2) Assainir le DNS côté clients
- Chaque client doit pointer uniquement vers l’IP du DC comme DNS primaire. Proscrire les DNS publics/box.
- Purger et redécouvrir :
ipconfig /flushdns,ipconfig /registerdns. - Tester la découverte du DC :
nltest /dsgetdc:MONDOMAINE.local.
3) Réparer le canal sécurisé poste ↔ domaine
Intervenir depuis la machine (session administrateur local si la session domaine échoue). Préférez PowerShell :
# 1) Tentative standard (réinitialise le secret machine côté client et AD)
Test-ComputerSecureChannel -Repair -Credential 'MONDOMAINE\Admin'
# 2) Variante explicite (utile si plusieurs DC ou résolution DNS instable)
Reset-ComputerMachinePassword -Server DC1 -Credential 'MONDOMAINE\Admin'
# 3) En CMD si PowerShell indisponible
nltest /sc\_reset\:MONDOMAINEImportant : la réinitialisation de l’objet ordinateur dans ADUC ne suffit jamais à elle seule. Le secret doit aussi être régénéré depuis la machine. Notez que netdom resetpwd s’adresse principalement aux DC ; pour un poste/serveur membre, utilisez plutôt Test‑ComputerSecureChannel, Reset‑ComputerMachinePassword, nltest /sc_reset ou netdom reset <NomMachine>.
4) Gérer les cas fréquents
- Machines jointes après la date de sauvegarde : leur objet n’existe plus dans l’AD restauré. Disjoignez (workgroup) puis rejoignez le domaine :
Remove-Computer -UnjoinDomainCredential (Get-Credential) -Restart # après redémarrage Add-Computer -DomainName 'MONDOMAINE.local' -Credential (Get-Credential) -Restart - Horloge juste & DNS corrects mais échec persistant : faire la séquence disjonction → jonction ci‑dessus pour repartir à neuf.
- SYSVOL absent : corriger la réplication/état de SYSVOL avant de s’acharner sur les postes, sinon les GPO ne se mettront pas à jour.
5) Industrialiser le traitement en masse
Pour des dizaines/centaines de machines :
- Opérer par lots (serveurs d’abord), en maintenant un canal de secours (RDP/iLO/console).
- Utiliser des comptes locaux (LAPS recommandé) ou un gMSA pour l’exécution distante. Éviter les mots de passe en clair dans des GPO de démarrage.
- Prérequis réseau : WinRM activé, pare‑feu ouvert (gestion distante), résolution DNS opérationnelle.
Exemple de script d’orchestration (lancé depuis un poste d’admin) :
$cred = Get-Credential # compte disposant d'admin local sur les cibles
$computers = Get-Content .\liste_machines.txt # un nom de machine par ligne
foreach (\$c in \$computers) {
try {
Write-Host "\[\$c] Réparation du canal sécurisé..."
Invoke-Command -ComputerName \$c -Credential \$cred -ScriptBlock {
param(\$domain,\$server)
\# Sanity check DNS (facultatif)
ipconfig /flushdns | Out-Null
\# Tentative 1 : réparation simple
\$ok = Test-ComputerSecureChannel -Repair -Credential "\$domain\Admin" -ErrorAction SilentlyContinue
if (-not \$ok) {
\# Tentative 2 : cible un DC précis
Reset-ComputerMachinePassword -Server \$server -Credential "\$domain\Admin"
}
\# Forcer une mise à jour des GPO
gpupdate /target\:computer /force | Out-Null
} -ArgumentList 'MONDOMAINE','DC1'
Write-Host "\[\$c] OK" -ForegroundColor Green
} catch {
Write-Warning "\[\$c] échec via WinRM. Basculer en plan B (disjoindre/rejoindre manuel)."
}
}6) Stabilisation post‑rétablissement
- GPO :
gpupdate /forcesur les machines réparées. - Renforcer la résilience :
- Déployer au moins un second DC (site différent si possible).
- Planifier des sauvegardes État du Système régulières avec rétention < durée de tombstone (par défaut ~180 jours sur les versions modernes).
- Superviser DNS/DFSR/Time/Netlogon, alerter sur les erreurs critiques.
- Sécurité : ne réinitialisez le
KRBTGTqu’une fois l’environnement stabilisé ; faire deux rotations espacées est une bonne pratique, mais pas pendant le dépannage.
Tableau de décision rapide
| Âge de la sauvegarde | Risque AD | Action recommandée |
|---|---|---|
| < 60 jours | Secret machines souvent désaligné, mais récupérable | Réparer secure channel poste par poste ; vérifier DNS/heure/SYSVOL |
| 60–180 jours | Nombreux réappairages à prévoir | Même approche ; prévoir disjonction/re‑jonction pour machines récentes |
| > 180 jours (tombstone par défaut) | Objets supprimés purgés ; risque élevé d’incohérences | Envisager une récupération de forêt / reconstruction complète |
Commandes utiles — mémo
| Commande | Où | Usage |
|---|---|---|
netdom query fsmo | DC | Lister les rôles FSMO |
dcdiag /test:DNS | DC | Valider la santé DNS AD‑intégré |
w32tm /query /status | DC | Contrôler la synchro temps |
nltest /dsgetdc:DOMAINE | Client | Découvrir un DC disponible |
Test-ComputerSecureChannel -Repair | Client | Réparer le canal sécurisé |
Reset-ComputerMachinePassword -Server DC1 | Client | Renouveler explicitement le secret avec un DC donné |
nltest /sc_reset:DOMAINE | Client | Réinitialiser le secure channel (CMD) |
gpupdate /force | Client | Forcer l’application des GPO |
Arbre de décision (texte)
- Le DC est‑il sain ? (services OK, SYSVOL/NETLOGON partagés, DNS répond, heure synchro) → Si NON, corrigez avant toute action client.
- Le client pointe‑t‑il vers le DNS du DC ? → Si NON, corriger et tester
nltest /dsgetdc. - Réparer le secure channel →
Test-ComputerSecureChannel -Repair. Si échec :Reset-ComputerMachinePassworden ciblant le DC. - Échec persistant ? → Disjoindre (workgroup) puis rejoindre le domaine.
- Machines apparues après la sauvegarde ? → Disjoindre/rejoindre directement (pas d’objet AD à l’instant T‑159).
Cas spéciaux & subtilités
- Environnement initialement multi‑DC : la restauration d’un DC ancien peut causer des incohérences (USN rollback, objets persistants). Si d’autres DC existent encore, isolez le DC restauré du réseau jusqu’à une stratégie de restauration/autoritative restore clairement définie.
- DFSR après restauration : il peut retarder la publication de
SYSVOL(protection post‑crash). Surveillez les événements DFSR et reprenez la réplication si nécessaire, puis vérifiez que\\DC\SYSVOLet\\DC\NETLOGONsont accessibles. - RODC : un Read‑Only DC ne répare pas les secrets machines. Ciblez un DC en écriture pour
Reset‑ComputerMachinePassword. - Ordinateurs portables hors site : prévoir un plan offline (compte local, VPN qui s’établit avant logon, portail de réinitialisation) ou un passage en atelier.
- NetBIOS vs FQDN : utilisez de préférence le FQDN du domaine (
MONDOMAINE.local) et un DC en FQDN (dc1.mondomaine.local) pour éviter les résolutions ambiguës. - Netdom reset vs resetpwd :
netdom resetcible un poste/serveur membre ;netdom resetpwdvise surtout un DC. En cas de doute, réparez depuis la machine avec PowerShell.
Exemples concrets et retours d’expérience
- Petite infra (1 DC + 40 postes) : après restauration J‑150, 70 % des postes récupérés avec
Test‑ComputerSecureChannel -Repair. Les 30 % restants (créés après J‑150) ont nécessité disjonction/re‑jonction. Temps de résolution : ~1 journée. - Site distant avec DNS public configuré sur routeur : tous les postes en échec. Correction du DHCP Option 006 vers l’IP du DC +
ipconfig /flushdns; 100 % des postes réparés parReset‑ComputerMachinePassword. - SYSVOL non partagé : aucune GPO appliquée, même après réparation de la confiance. Déblocage DFSR → publication SYSVOL →
gpupdate /force→ succès.
Bonnes pratiques pour ne plus revivre ce scénario
- Deux DC minimum (sites/logements d’énergie différents si possible).
- Sauvegardes État du Système hebdomadaires + test de restauration. Conservez‑les moins longtemps que la tombstone par défaut, ou bien documentez une procédure de restauration de forêt.
- Supervision systématique : événements Netlogon, DFSR, Time‑Service, KDC, DNS. Alerte dès échec.
- Temps : PDC Emulator source « référence », NTP fiable,
w32tmconforme, marges Kerberos respectées. - DNS : serveurs/clients ne doivent interroger que le DNS AD‑intégré pour la zone du domaine. Véto sur les DNS externes dans la pile NIC.
- Automatisation sécurisée : LAPS pour les comptes locaux, gMSA pour les tâches planifiées, aucun secret en clair.
FAQ express
Réparer depuis le DC aide‑t‑il ? Non : c’est la machine membre qui initie et stocke son secret. Il faut le régénérer localement (ou via exécution distante sur la machine).
Peut‑on éviter de disjoindre/rejoindre ? Oui la plupart du temps, si l’objet ordinateur existe encore et que DNS/heure sont corrects. Sinon, la ré‑adhésion est la voie la plus rapide.
Faut‑il réinitialiser KRBTGT immédiatement ? Non. Attendez que l’environnement soit stable, puis procédez de façon contrôlée.
Procédure « minute » (copier‑coller)
# Sur le DC
dcdiag /test:DNS
netdom query fsmo
w32tm /config /manualpeerlist:"ntp.exemple.tld" /syncfromflags:manual /reliable:yes /update
w32tm /resync /nowait
net stop netlogon & net start netlogon
nltest /dsregdns
# Sur un poste (session admin local)
ipconfig /flushdns
nltest /dsgetdc\:MONDOMAINE.local
Test-ComputerSecureChannel -Repair -Credential 'MONDOMAINE\Admin'
# si échec
Reset-ComputerMachinePassword -Server DC1 -Credential 'MONDOMAINE\Admin'
# si encore échec
Remove-Computer -UnjoinDomainCredential (Get-Credential) -Restart
# puis après reboot
Add-Computer -DomainName 'MONDOMAINE.local' -Credential (Get-Credential) -RestartPoints d’attention critiques
- Ne mélangez jamais DNS publics et DNS AD sur les clients.
- Réparez le temps et SYSVOL avant de traiter les postes en masse.
- Le simple « Reset Account » dans ADUC n’est pas une réparation complète.
- Documentez la date de la sauvegarde et adaptez vos attentes : plus elle est ancienne, plus vous aurez de machines à disjoindre/rejoindre.
Conclusion
La perte de relation d’approbation après la restauration d’un DC ancien est logique : les secrets ont divergé. En sécurisant d’abord le DC (services, DNS, temps, SYSVOL), puis en réparant les canaux sécurisés depuis les machines — et en disjoignant/rejoignant celles créées après la sauvegarde — vous revenez à un état stable, industrialisable et durable. Scellez enfin le tout par de bonnes pratiques : second DC, sauvegardes régulières et supervision.