Sur une VM Windows Server 2016, l’erreur « The security database on the server does not have a computer account for this workstation trust relationship » réapparaît à intervalles réguliers. Voici un guide terrain, concret et reproductible, pour diagnostiquer la cause racine et corriger durablement (0xC000018B, NULL SID).
Erreur récurrente « The security database on the server does not have a computer account for this workstation trust relationship » sur VM Windows Server 2016
Vue d’ensemble
Sur une VM Windows Server 2016, la connexion au domaine échoue tous les quelques jours avec le message ci‑dessus. L’Observateur d’événements montre des échecs d’ouverture de session (Audit Failure) où Security ID = NULL SID et Failure Status = 0xC000018B. Les remèdes classiques ont déjà été tentés (resynchronisation NTP, vérification SPN, gpupdate, réinitialisation du compte machine côté AD et via netdom, nettoyage DNS, ADSIEdit, sortie/réintégration au domaine) mais l’incident revient.
Ce que signifie exactement le code d’erreur observé
- 0xC000018B = STATUS_NO_TRUST_SAM_ACCOUNT : le contrôleur de domaine ne trouve pas de compte ordinateur valide pour l’hôte qui s’authentifie, ou le canal sécurisé (secure channel) avec le domaine est rompu (mot de passe du compte machine désynchronisé).
- NULL SID dans l’événement 4625 indique qu’aucun compte n’a pu être associé à la tentative d’ouverture de session, ce qui est typique quand la machine n’arrive plus à prouver son identité auprès du DC.
Contexte utile : dans un domaine Active Directory, chaque poste possède un mot de passe de compte machine. Par défaut, il est renouvelé tous les 30 jours. Si, pour une raison quelconque, la machine et l’AD n’ont plus la même valeur, la relation d’approbation se brise et le secure channel échoue.
| Symptôme | Signification | Impact |
|---|---|---|
| 0xC000018B (STATUS_NO_TRUST_SAM_ACCOUNT) | Le DC ne reconnaît pas le secret (mot de passe) du compte machine | Échec d’authentification machine, rupture du secure channel |
| Security ID = NULL SID | Aucun SID utilisateur/machine associé à la tentative | La requête n’a pas franchi l’étape d’identification |
Causes probables (classées par probabilité pour une VM)
- Instantanés / restaurations / clones de VM : un revert de snapshot, un test de restauration (Instant Recovery), ou un clone démarré sur le réseau avec la même identité réintroduit un ancien mot de passe machine. Le DC garde la valeur la plus récente, d’où la désynchronisation et la récidive « tous les quelques jours ». C’est la cause la plus fréquente dans les environnements virtualisés.
- Réplication AD / choix du DC : en présence de plusieurs DC, un défaut de réplication (ou une topologie de sites imprécise) peut faire alterner la VM entre un DC « à jour » et un DC « en retard », entraînant des cycles échec/succès.
- Paramétrage GPO/registre anormal autour des mots de passe de compte machine (ex. Disable machine account password changes activé, ou Maximum password age réglé de manière aberrante). C’est moins souvent la cause d’une rupture récurrente, mais cela peut l’entretenir.
| Scénario | Indice observable | Vérification rapide |
|---|---|---|
| Snapshot / clone en prod | Incident revient après tests sauvegarde / maintenance | Inventaire des snapshots / journaux de sauvegarde |
| Réplication AD dégradée | Succès avec DC-A, échec avec DC-B | repadmin /replsummary, repadmin /showrepl * |
| GPO/registre | Changements de mot de passe désactivés | Clés Netlogon, RSOP / GPResult |
Plan de diagnostic ciblé
Sur la VM affectée
1) Identifier le DC contacté et l’état du secure channel
set | find /i "LOGONSERVER"
nltest /sc_query:<NetBIOSDuDomaine>
nltest /sc_verify:<NetBIOSDuDomaine>
Test-ComputerSecureChannel -Verbose
%LOGONSERVER%indique le DC utilisé par la session actuelle (utile pour corréler les journaux côté DC).nltestetTest-ComputerSecureChannelconfirment si le secure channel est sain.
2) Activer le logging Netlogon (temporaire)
nltest /DBFlag:0x2080FFFF
rem Désactiver ensuite : nltest /DBFlag:0x0
Les traces sont écrites dans %windir%\debug\netlogon.log. N’oubliez pas de revenir à 0x0 une fois l’analyse terminée.
3) Vérifier les paramètres Netlogon locaux (registre)
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /v DisablePasswordChange
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /v MaximumPasswordAge
| Clé | Type | Valeur attendue | Effet |
|---|---|---|---|
| DisablePasswordChange | REG_DWORD | 0 (activé) | Autorise la rotation automatique du mot de passe machine |
| MaximumPasswordAge | REG_DWORD | 30 (jours, par défaut) | Âge maxi du mot de passe machine avant rotation |
4) Valider l’heure et la topologie (rapide)
w32tm /query /status
w32tm /query /configuration
nltest /dsgetsite
nltest /dclist:<NetBIOSDuDomaine>
- Une dérive d’heure (> 5 minutes) peut bloquer Kerberos. Même si une resynchronisation a été tentée, validez le mécanisme NTP.
/dsgetsiteet/dclistaident à comprendre vers quel DC la machine devrait aller.
Côté Active Directory / DC
1) Événements Netlogon
- Rechercher Netlogon 5722 / 5805 / 5723 sur les DC : ils confirment les échecs d’authentification du compte machine et indiquent l’hôte concerné.
- Sur le poste, l’événement 3210 Netlogon est souvent présent lors d’une rupture.
| Événement | Source | Résumé |
|---|---|---|
| 5722 | NETLOGON (DC) | La machine a fourni un mot de passe incorrect pour son compte |
| 5805 | NETLOGON (DC) | Le compte ordinateur n’existe pas ou ne correspond pas |
| 5723 | NETLOGON (DC) | Échec de l’approbation de l’ordinateur |
| 3210 | NETLOGON (poste) | Échec de validation de la relation d’approbation |
2) Réplication AD
repadmin /replsummary
repadmin /showrepl *
dcdiag /test:Connectivity /test:Advertising /v
La réplication doit être propre. S’il existe des écarts, corrigez-les avant de réinitialiser le secure channel pour éviter qu’un DC « en retard » ne réintroduise l’erreur.
3) Contrôler l’objet ordinateur dans l’AD
Get-ADComputer <NomMachine> -Properties PasswordLastSet, PwdLastSet, LastLogonTimestamp, ServicePrincipalName | fl
- Notez PwdLastSet/PasswordLastSet : date du dernier changement. Comparez aux événements côté VM (pattern de récidive).
- Vérifiez l’OU, les SPN, et d’éventuels duplicates (machines clonées).
Dans l’infrastructure de virtualisation / sauvegarde
- Listez/supprimez les snapshots anciens (ou checkpoints). Les conserver sur des VM jointes au domaine est risqué.
- Vérifiez les tests de restauration (Instant Recovery, bac à sable, validations de sauvegarde) : s’exécutent-ils sur le réseau de production ? Y a‑t‑il démarrage périodique d’un clone avec le même nom ?
- Si un clone doit être maintenu, isolez‑le (réseau de labo) ou changez son nom/domaine.
Correctifs efficaces
A. Remise en état immédiate (sans dé/rajointure si possible)
Depuis la VM (session locale administrateur) :
# Test et réparation vers un DC précis (recommandé)
Test-ComputerSecureChannel -Repair -Server <NomDC> -Verbose
Alternative :
# Réinitialiser explicitement le mot de passe du compte machine
Reset-ComputerMachinePassword -Server <NomDC> -Credential (Get-Credential)
Ou en ligne de commande :
nltest /sc_reset:<Domaine>\<NomDC>
- Astuce : ciblez de préférence le PDC Emulator ou un DC local au site AD pour réduire les surprises de réplication.
- Selon la santé de l’AD et les ACL, une élévation de privilèges (compte délégué ou admin domaine) peut être requise pour
Reset-ComputerMachinePassword.
Plan B (si la réparation échoue) :
- Sortir du domaine (reboot),
- Supprimer le compte ordinateur en AD (ou le réinitialiser),
- Rejoindre à nouveau le domaine (reboot),
- Vérifier
gpupdate /forceet l’application des GPO.
Ce plan B est plus intrusif et ne traite pas la cause racine. Utilisez-le en dernier recours.
B. Éviter la récidive (traitement de la cause racine)
- Si snapshots / clones :
- Supprimez les checkpoints conservés longtemps sur des serveurs en production.
- N’exécutez pas de clones sur le réseau de prod avec la même identité.
- Pour des retours fréquents à un état antérieur : prévoyez un script de réparation au démarrage (
Test-ComputerSecureChannel -Repair) ou désactivez temporairement la rotation automatique du mot de passe machine uniquement pour cette VM (avec compréhension de l’impact sécurité ; non recommandé en prod).
- Si réplication AD en cause :
- Corrigez sites/sous-réseaux, latences et erreurs
repadmin. - Assurez-vous que la VM s’authentifie sur un DC proche et à jour.
- Corrigez sites/sous-réseaux, latences et erreurs
- Si paramétrage Netlogon anormal :
- Remettez
DisablePasswordChange = 0etMaximumPasswordAge = 30jours (ou valeur conforme à votre politique). - Vérifiez RSOP/GPResult pour détecter une GPO qui surchargerait ces paramètres.
- Remettez
Playbook pas‑à‑pas (exécution rapide)
- Sur la VM :
Test-ComputerSecureChannel -Verbose. Si Broken : corriger avec-Repair -Server <PDC>. - Vérifier
%LOGONSERVER%et noter le DC utilisé ; corrélez avec les journaux Netlogon du DC. - Côté AD :
repadmin /replsummaryet/showrepl *. Corriger les erreurs s’il y en a. - Rechercher événements Netlogon 5722/5805/5723 (DC) et 3210 (client).
- Contrôler l’objet ordinateur :
Get-ADComputeravec PasswordLastSet. - Dans l’hyperviseur/sauvegarde : supprimer snapshots, désactiver tests de restauration sur réseau de prod, isoler clones.
- Vérifier et rétablir DisablePasswordChange et MaximumPasswordAge si besoin.
Automatiser une réparation au démarrage (option encadrée)
Si vous devez temporairement revenir à un snapshot (lab, dépannage), vous pouvez déclencher une auto‑réparation du secure channel à chaque boot. Idéalement, exécutez la tâche avec un compte de service délégué autorisé à réinitialiser le mot de passe du compte machine.
Script PowerShell de réparation défensive
# Fichier : C:\Scripts\Repair-SecureChannel.ps1
param(
[string]$PreferredDC
)
function Write-Log(\$Message, \$EventId = 3000, \$EntryType = "Information") {
\$source = "SecureChannelRepair"
if (-not \[System.Diagnostics.EventLog]::SourceExists(\$source)) {
New-EventLog -LogName Application -Source \$source -ErrorAction SilentlyContinue
}
Write-EventLog -LogName Application -Source \$source -EventId \$EventId -EntryType \$EntryType -Message \$Message
}
try {
Write-Log "Vérification du secure channel en cours..."
\$ok = Test-ComputerSecureChannel -Verbose -ErrorAction Stop
if (\$ok) {
Write-Log "Secure channel OK."
exit 0
}
}
catch {
Write-Log "Secure channel BRISÉ : \$($\_.Exception.Message)" 3001 "Warning"
}
try {
\$server = if (\$PreferredDC) { \$PreferredDC } else { \$env\:LOGONSERVER.TrimStart('') }
if (-not \$server) { \$server = (Get-ADDomainController -Discover -ErrorAction SilentlyContinue).HostName }
if (-not \$server) { \$server = \$env\:COMPUTERNAME } # dernier recours
Write-Log "Tentative de réparation via \$server..."
\$repaired = Test-ComputerSecureChannel -Repair -Server \$server -Verbose -ErrorAction Stop
if (\$repaired) {
Write-Log "Réparation secure channel réussie via \$server."
exit 0
} else {
Write-Log "Réparation secure channel NON confirmée." 3002 "Warning"
exit 1
}
}
catch {
Write-Log "Échec de réparation : \$($\_.Exception.Message)" 3003 "Error"
exit 2
} Créer une tâche planifiée (au démarrage)
schtasks /Create /TN "RepairSecureChannel" /TR "powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\Repair-SecureChannel.ps1 -PreferredDC <NomDC>" /SC ONSTART /RL HIGHEST /RU "<DOMAINE\CompteDelegue>" /RP *
Important : utilisez un compte de service minimement priviligié avec le droit « Réinitialiser le mot de passe » sur l’objet ordinateur (délégation sur l’OU cible). Évitez d’utiliser un compte Admin Domaine.
Bonnes pratiques et anti‑patterns
- À faire :
- Supprimer régulièrement les snapshots/checkpoints en prod.
- Isoler tout clone de validation de sauvegarde des réseaux de prod.
- Maintenir une topologie AD Sites/Subnets fidèle à la réalité réseau.
- Surveiller
repadmin,dcdiag, Netlogon et les événements 4625/5722/5805/3210.
- À éviter :
- Désactiver durablement la rotation des mots de passe machine (DisablePasswordChange = 1) : c’est un risque sécurité.
- Revenir régulièrement à un snapshot d’une VM jointe au domaine sans mécanisme de réparation automatisé.
- Laisser un clone démarrer sur le réseau de prod sans sysprep/changement d’identité.
Mémo de commandes (cheat‑sheet)
| Commande | But | Contexte |
|---|---|---|
set | find /i "LOGONSERVER" | DC ayant authentifié la session | Client |
Test-ComputerSecureChannel [-Repair] | Tester / réparer le secure channel | Client (PowerShell) |
nltest /sc_query:<Domaine> | État du secure channel | Client |
nltest /sc_reset:<Domaine>\<DC> | Réinitialiser vers un DC précis | Client |
nltest /DBFlag:0x2080FFFF | Activer traces Netlogon | Client (temporaire) |
repadmin /replsummary | Résumé réplication | DC |
repadmin /showrepl * | Détails partenaires | DC |
dcdiag /test:Connectivity /test:Advertising | Diagnostic DC | DC |
Get-ADComputer ... -Properties PwdLastSet | Voir dernier changement mot de passe machine | Outils AD |
w32tm /query /status | État temps/NTP | Client/DC |
Diagnostic avancé : comprendre la mécanique
Secure channel, LSA secrets et Kerberos
Le secure channel repose sur un secret partagé entre l’ordinateur et le domaine (stocké localement par LSA et côté DC). Lors de l’authentification, l’hôte prouve qu’il connaît ce secret ; si la valeur diverge, le DC renvoie 0xC000018B. Kerberos exige en plus une heure cohérente. Quand l’heure est bonne mais que le secret diverge, c’est quasi‑toujours le mot de passe machine.
Pourquoi les snapshots cassent‑ils la confiance ?
Un snapshot restaure un état ancien du disque et du registre : la VM revient avec un ancien secret LSA et un PwdLastSet dépassé. Pendant ce temps, l’AD a déjà enregistré des rotations ultérieures. Résultat : la valeur la plus récente au DC ne correspond plus à celle de la VM.
Et la réplication ?
Un changement de mot de passe machine est écrit sur un DC et doit être répliqué. Si la VM tombe parfois sur un DC qui n’a pas encore la nouvelle valeur, vous observez des logons intermittents. D’où l’intérêt de cibler le PDC Emulator pour la réparation, puis de s’assurer que la réplication est saine.
Procédure d’assainissement en production (check‑list)
- Immédiat : réparer le secure channel vers le PDC, valider
gpupdateet les partages SYSVOL/NETLOGON. - 24–48 h : supprimer snapshots, isoler clones, désactiver tests de restauration réseau de prod.
- Infra AD : corriger réplication, revoir Sites/Subnets, latence inter‑sites, DNS SRV.
- Gouvernance : consigner la procédure « DR/validation sauvegarde » pour éviter le démarrage en prod d’un clone non sysprepé.
- Surveillance : créer alertes sur 5722/5805/3210 et sur 0xC000018B dans 4625.
FAQ technique
Q : Peut‑on corriger en modifiant l’horloge uniquement ?
R : Non, l’erreur 0xC000018B signale un secret de compte machine invalide, pas seulement un problème d’horloge. La dérive d’heure provoque d’autres codes (skew Kerberos), pas celui‑ci.
Q : Test-ComputerSecureChannel -Repair nécessite‑t‑il des identifiants domaine ?
R : Il tente d’abord avec le compte machine. Si le canal est rompu, il peut échouer ; utilisez alors un compte déjà délégué pour réinitialiser le mot de passe du compte ordinateur (ou un admin domaine).
Q : Réduire MaximumPasswordAge résout‑il l’incident ?
R : Non. La rotation plus fréquente ne corrige pas un snapshot/clonage qui restaure un secret ancien, elle peut même multiplier les divergences.
Q : Et si je ne peux pas éviter les snapshots (ex. audit, forensic) ?
R : Isolez l’interface réseau, appliquez un script de réparation au démarrage, et documentez la re‑jointure au domaine si nécessaire. Ne laissez pas cette VM interagir avec les DC de production tant que l’identité n’est pas régénérée.
Annexes
Filtre d’affichage dans l’Observateur d’événements
Pour repérer rapidement les tentatives connexes :
- Journal : Security
- ID : 4625 (échec logon), 4768/4771 (Kerberos), 3210 (Netlogon) côté client
- Mots‑clés : Failure Status = 0xC000018B, Security ID = NULL SID
Exemple de rapport de cause racine (RCA) type
Symptôme : Échecs 4625 avec 0xC000018B, NULL SID, tous les 2–3 jours.
Cause racine : Démarrage automatique d’un clone de sauvegarde sur réseau de prod pendant tests hebdo, réintroduisant un ancien mot de passe machine.
Correctif : Isolation du job de test sur VLAN labo + suppression checkpoints + réparation secure channel sur PDC.
Prévention : Politique « zéro clone en prod », alertes Netlogon et contrôle réplication mensuel.
En bref – plan d’action recommandé
- Réparer immédiatement le secure channel (
Test-ComputerSecureChannel -Repair,Reset-ComputerMachinePasswordounltest /sc_reset). - Éliminer la cause la plus probable : snapshot/clone/restauration qui démarre sur le réseau de production.
- Contrôler la réplication AD et les événements NETLOGON 5722/5805/5723 (et 3210 côté client).
- Vérifier les paramètres Netlogon/GPO : ne pas désactiver la rotation du mot de passe machine sans justification exceptionnelle.
Ce duo remise en état + traitement de la cause racine (très souvent un revert/clone de VM) est la voie la plus fiable pour éviter la récidive de l’erreur « The security database on the server does not have a computer account for this workstation trust relationship » et des codes 0xC000018B/NULL SID associés.