MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Réparer « Trust Relationship » rompue entre poste Windows et domaine Active Directory

Réparer « Trust Relationship » rompue entre poste Windows et domaine Active Directory

Windows Server

Votre PC joint au domaine affiche « There is no logon server available » ou « The security database… trust relationship » ? Ce guide terrain vous aide à diagnostiquer et réparer une rupture de canal sécurisé Active Directory, sans perte de profil ni casse GPO.

Sommaire

Vue d’ensemble de la question

Sur un poste Windows membre d’un domaine Active Directory, deux symptômes reviennent :

  • Connexion impossible au domaine avec le message There is no logon server available to service the logon request lors d’une ouverture de session réseau : le poste ne parvient pas à contacter un contrôleur de domaine (DC).
  • Échec de (re)jonction au domaine avec le message The security database on the server does not have a computer account for this workstation trust relationship. La connexion locale fonctionne hors réseau, mais la tentative de réintégration échoue.

Dans la plupart des cas, le canal sécurisé machine ↔ DC (basé sur le mot de passe du compte ordinateur) est désynchronisé ou le poste ne peut pas joindre un DC à cause d’un problème DNS/heure/réseau. Point clé : un compte local ne permet pas de joindre un domaine. Lors de la jonction, on doit fournir des identifiants de domaine (ex. CONTOSO\Administrateur).

Pourquoi la relation d’approbation casse

  • Mot de passe du compte ordinateur périmé ou incohérent (rotation régulière côté poste vs. valeur stockée dans AD) après un revert de snapshot/clone non sysprepé, une restauration d’image, ou un long arrêt hors réseau.
  • Impossibilité réseau de joindre un DC (DNS publics configurés, VPN déconnecté, ports bloqués, pare-feu local, site AD mal résolu).
  • Dérive horaire (> 5 minutes) rompant Kerberos.
  • Objet ordinateur en AD absent, désactivé, dupliqué ou corrompu.
  • GPO ou configuration empêchant la rotation du mot de passe machine.

Checklist minute avant toute action

À vérifierCommandes rapidesCe qu’on attend
DNS interne uniquementipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4		Serveurs DNS = DC internes, jamais du public (8.8.8.8, etc.).
Heure synchroniséew32tm /query /status
w32tm /resync		Écart < 5 minutes avec les DC.
Découverte d’un DCnltest /dsgetdc:contoso.localRenvoie un DC du bon site.
État du canal sécurisénltest /sc_query:contoso.localTrusted DC Connection = OK.
Latence réseau de baseping <NomOuIP_DC>Réponses stables < 20–100 ms selon le site.

Diagnostic rapide

Si DNS interne + heure + connectivité sont OK, la rupture vient presque toujours d’un secret machine désynchronisé. Réparez le canal sécurisé avec PowerShell ou les outils en ligne de commande, puis redémarrez.

Chemin A — Réparer sans sortir du domaine (DC joignable)

  1. Se connecter en administrateur local (si besoin, débranchez le réseau pour forcer l’ouverture de session locale).
  2. Rebrancher le réseau et valider l’accès au DC (voir la checklist).
  3. Ouvrir PowerShell en administrateur et exécuter : Test-ComputerSecureChannel Test-ComputerSecureChannel -Repair -Credential (Get-Credential) # fournir un compte du domaine autorisé # Alternative (équivalent technique) : Reset-ComputerMachinePassword -Credential (Get-Credential)
  4. Redémarrer puis tester une ouverture de session avec un compte du domaine.

Commandes alternatives

nltest /sc_verify:contoso.local
nltest /sc_reset:contoso.local /server:DC01

netdom resetpwd /server\:DC01 /domain\:contoso.local /userd\:contoso\admin /passwordd:\* </code></pre>

<table>
  <thead>
    <tr>
      <th>Commande</th>
      <th>Usage</th>
      <th>Remarques</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code>Test-ComputerSecureChannel -Repair</code></td>
      <td>Répare le canal sécurisé côté poste via un DC joignable.</td>
      <td>Pratique et moderne; nécessite des droits d’un compte de domaine.</td>
    </tr>
    <tr>
      <td><code>nltest /sc_reset</code></td>
      <td>Réinitialise le secret machine avec un DC ciblé.</td>
      <td>Utile si une topologie multi-sites complique la découverte.</td>
    </tr>
    <tr>
      <td><code>netdom resetpwd</code></td>
      <td>Réécrit le mot de passe du compte ordinateur.</td>
      <td>Très efficace en environnement scripté ou sur anciennes versions.</td>
    </tr>
  </tbody>
</table>

<h2>Chemin B — Sortir puis réintégrer le domaine (méthode GUI classique)</h2>
<ol>
  <li>Connexion locale &rarr; <strong>Propriétés du système</strong> &rarr; <strong>Nom de l’ordinateur</strong> &rarr; <strong>Modifier</strong> &rarr; basculer en <strong>Workgroup</strong> (ex.&nbsp;<code>WORKGROUP</code>) &rarr; redémarrer.</li>
  <li>Connexion locale &rarr; <strong>Modifier</strong> &rarr; choisir <strong>Domain</strong> &rarr; saisir <code>contoso.local</code>.</li>
  <li><strong>À l’invite d’identification</strong>, fournir un <strong>compte du domaine habilité</strong> (ex.&nbsp;<code>CONTOSO\admin-domaine</code>) &rarr; redémarrer.</li>
</ol>
<p><em>Important&nbsp;:</em> les <strong>identifiants locaux</strong> sont <strong>refusés</strong> à cette étape. C’est la cause la plus fréquente d’échec observé lors d’une réintégration.</p>

<h3>Équivalents en ligne de commande</h3>
<pre><code class="language-powershell">Add-Computer -DomainName "contoso.local" -Credential contoso\admin `
  -OUPath "OU=Workstations,DC=contoso,DC=local" -Restart

# ou mode CMD

netdom join %COMPUTERNAME% /domain\:contoso.local /userd\:contoso\admin /passwordd:\* </code></pre>

<h2>Chemin C — Réparation avancée hors ligne (sites distants, VPN absent)</h2>
<p>Si le poste ne peut <strong>pas</strong> joindre un DC (pas de VPN, site isolé), la jonction standard échoue. Une option est la <strong>jonction de domaine hors ligne</strong> (<code>djoin.exe</code>)&nbsp;:</p>
<ol>
  <li>Sur un PC <em>déjà</em> joint au domaine et autorisé à créer des objets ordinateurs&nbsp;:
    <pre><code class="language-batch">djoin /provision /domain contoso.local /machine POSTE123 /savefile C:\odjblob.txt /reuse</code></pre>
  </li>
  <li>Copier le fichier <code>odjblob.txt</code> sur le poste cible et appliquer&nbsp;:
    <pre><code class="language-batch">djoin /requestODJ /loadfile C:\odjblob.txt /windowspath C:\Windows /localos</code></pre>
  </li>
  <li>Redémarrer. La machine est <em>pré-jointe</em>; dès que la connectivité au DC sera rétablie, le canal sécurisé se stabilisera. Pour l’ouverture de session avec un compte de domaine, la présence d’un DC reste nécessaire.</li>
</ol>
<p><em>Note</em>&nbsp;: l’ODJ n’est pas une baguette magique. Il prépare l’objet et la configuration, mais un DC joignable reste requis pour authentifier les comptes du domaine.</p>

<h2>Vérifications indispensables et commandes utiles</h2>
<h3>DNS</h3>
<ul>
  <li>La carte réseau doit <strong>uniquement</strong> pointer vers les DNS internes/contrôleurs de domaine.</li>
  <li>Purgez le cache et renouvelez l’IP si besoin&nbsp;:
    <pre><code class="language-batch">ipconfig /flushdns
ipconfig /registerdns
ipconfig /release &amp;&amp; ipconfig /renew
</code></pre>
  </li>
</ul>

<h3>Temps</h3>
<pre><code class="language-batch">w32tm /query /status
w32tm /resync /nowait
</code></pre>

<h3>Connectivité vers les DC</h3>
<pre><code class="language-batch">nltest /dsgetdc:contoso.local
nltest /sc_query:contoso.local
ping DC01
telnet DC01 389
</code></pre>

<h3>Ports à autoriser</h3>
<table>
  <thead>
    <tr>
      <th>Service</th>
      <th>Ports</th>
      <th>Protocole</th>
      <th>Objet</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Kerberos</td>
      <td>88</td>
      <td>TCP/UDP</td>
      <td>Authentification</td>
    </tr>
    <tr>
      <td>LDAP / LDAPS</td>
      <td>389 / 636</td>
      <td>TCP/UDP (389), TCP (636)</td>
      <td>Annuaire, jonction</td>
    </tr>
    <tr>
      <td>SMB</td>
      <td>445</td>
      <td>TCP</td>
      <td>Netlogon, scripts, SYSVOL</td>
    </tr>
    <tr>
      <td>RPC Endpoint Mapper</td>
      <td>135</td>
      <td>TCP</td>
      <td>DCOM</td>
    </tr>
    <tr>
      <td>RPC dynamiques</td>
      <td>49152–65535</td>
      <td>TCP</td>
      <td>Appels RPC Netlogon, AD</td>
    </tr>
    <tr>
      <td>NTP</td>
      <td>123</td>
      <td>UDP</td>
      <td>Synchronisation horaire</td>
    </tr>
  </tbody>
</table>

<h3>Droits &amp; objet AD</h3>
<ul>
  <li>Dans la console ADUC, vérifier que l’objet <strong>Computer</strong> existe, est dans la bonne OU, et n’est pas <strong>Disabled</strong>.</li>
  <li>Si doute, tenter <em>Reset Account</em> puis réintégrer, ou supprimer/récréer l’objet.</li>
</ul>

<h3>Pare-feu/VPN</h3>
<p>S’assurer que le poste atteint un DC (LAN ou VPN). Sur VPN, valider la résolution DNS vers les DC du domaine et l’accès SYSVOL/NETLOGON (<code>\\contoso.local\sysvol</code>).</p>

<h2>Lecture des journaux d’événements</h2>
<table>
  <thead>
    <tr>
      <th>Journal</th>
      <th>Événements utiles</th>
      <th>Interprétation</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Système &rarr; <em>Netlogon</em></td>
      <td>5719, 5722, 5805, 5816</td>
      <td>Pas de DC dispo, échec d’auth machine, canal sécurisé rompu.</td>
    </tr>
    <tr>
      <td>Sécurité</td>
      <td>4771, 4768</td>
      <td>Échecs Kerberos, tickets refusés (horloge, SPN, secret).</td>
    </tr>
    <tr>
      <td>DNS Client</td>
      <td>1014</td>
      <td>Résolution impossible du nom du domaine ou du DC.</td>
    </tr>
  </tbody>
</table>

<h2>Cas particuliers et erreurs proches</h2>
<ul>
  <li><strong>RODC</strong>&nbsp;: la réinitialisation de mot de passe machine requiert un DC <em>écrivable</em>. Forcer le DC cible avec <code>nltest /sc_reset</code>.</li>
  <li><strong>Snapshots/Clones</strong>&nbsp;: toujours <em>sysprep</em> avant duplication. Éviter les retours d’instantanés sur une machine jointe.</li>
  <li><strong>Renommage</strong> du poste&nbsp;: si l’objet AD reste avec l’ancien nom, supprimer/réassocier.</li>
  <li><strong>SPN/Duplicats</strong>&nbsp;: vérifiez l’unicité du nom machine. Les duplicats causent des anomalies Kerberos.</li>
  <li><strong>Comptes mis en cache</strong>&nbsp;: une ouverture de session «&nbsp;offline&nbsp;» peut réussir avec des identifiants de domaine mis en cache, mais <em>ne répare pas</em> le canal sécurisé.</li>
  <li><strong>Azure AD vs AD DS</strong>&nbsp;: <code>dsregcmd /status</code> renseigne l’état AAD/Hybrid, distinct du canal sécurisé AD DS.</li>
</ul>

<h2>Contrôles de configuration et GPO</h2>
<p>Deux paramètres influent directement sur la fiabilité du canal sécurisé&nbsp;:</p>
<ul>
  <li><strong>Domain member: Maximum machine account password age</strong> (par défaut ~30 jours). Le réduire augmente la charge; le désactiver fragilise la sécurité.</li>
  <li><strong>Domain member: Disable machine account password changes</strong>&nbsp;: laissez <em>Désactivé</em> pour autoriser la rotation.</li>
</ul>
<p>Vérification rapide côté registre&nbsp;:</p>
<pre><code class="language-batch">reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /v MaximumPasswordAge
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters /v DisablePasswordChange
</code></pre>
<p>Inspection des stratégies appliquées&nbsp;:</p>
<pre><code class="language-batch">gpresult /h C:\gpresult.html
start C:\gpresult.html
</code></pre>

<h2>Procédure de remédiation à grande échelle</h2>
<p>Pour traiter une salve de postes dans une OU, utilisez PowerShell Remoting (WinRM activé) et consignez les résultats&nbsp;:</p>
<pre><code class="language-powershell">$ou = "OU=Workstations,DC=contoso,DC=local"
$creds = Get-Credential contoso\admin
$computers = Get-ADComputer -SearchBase $ou -Filter * | Select-Object -Expand Name

\$report = foreach (\$c in \$computers) {
try {
Invoke-Command -ComputerName \$c -ScriptBlock {
\$before = Test-ComputerSecureChannel
if (-not \$before) {
Test-ComputerSecureChannel -Repair -Credential \$using\:creds | Out-Null
}
\$after = Test-ComputerSecureChannel
\[PSCustomObject]@{ Computer=\$env\:COMPUTERNAME; Before=\$before; After=\$after; Timestamp=Get-Date }
} -ErrorAction Stop
} catch {
\[PSCustomObject]@{ Computer=\$c; Before=\$null; After=\$false; Timestamp=Get-Date; Error=$\_.Exception.Message }
}
}
\$report | Export-Csv C:\Repair-SecureChannel.csv -NoTypeInformation </code></pre>

<p>Idée&nbsp;: planifier ce correctif ciblé sur les sites affectés (concentrations d’erreurs Netlogon 5719/5805).</p>

<h2>Post-vérifications et validation</h2>
<ul>
  <li><strong>Canal sécurisé</strong> de nouveau OK&nbsp;:
    <pre><code class="language-batch">nltest /sc_verify:contoso.local</code></pre>
  </li>
  <li><strong>Tickets Kerberos propres</strong>&nbsp;:
    <pre><code class="language-batch">klist purge</code></pre>
  </li>
  <li><strong>Politique appliquée</strong> et scripts de logon&nbsp;:
    <pre><code class="language-batch">gpupdate /force
echo %LOGONSERVER%
whoami /fqdn
</code></pre>
  </li>
  <li><strong>Accès SYSVOL/NETLOGON</strong>&nbsp;:
    <pre><code class="language-batch">dir \\contoso.local\sysvol
dir \\contoso.local\netlogon

Conseils de prévention

  • Configurer les postes pour utiliser exclusivement les DNS internes.
  • Assurer une synchronisation NTP fiable poste ↔ DC, y compris sur sites distants.
  • Éviter les retours de snapshot non sysprepés sur des machines joignant le domaine.
  • Déployer LAPS/LAPS Cloud ou approche équivalente pour gérer le mot de passe admin local en sécurité.
  • Superviser les événements Netlogon, l’échec de jonction et les dérives d’horloge.
  • Documenter le flux de remédiation et automatiser le chemin A.

FAQ express

Q : Puis-je réparer avec un compte local ?
R : Non. La réparation et la jonction exigent des identifiants de domaine détenant le droit de joindre (ou délégués sur l’OU cible).

Q : Sortir du domaine supprime-t-il les profils utilisateur ?
R : Non, les profils restent sur disque. Mais les SID de domaine ne sont plus résolus tant que la machine n’est pas réintégrée.

Q : En site isolé sans DC, que puis-je faire ?
R : Utiliser djoin pour préparer la jonction, puis finaliser quand la connectivité DC revient. Pour ouvrir une session domaine, la présence d’un DC reste requise.

Q : Le message « There is no logon server available… » disparaît mais la jonction échoue encore.
R : Inspectez l’objet Computer en AD, les GPO de mot de passe machine, et purgez les tickets Kerberos (klist purge).

Q : Comment limiter l’impact BitLocker ?
R : Sauvegardez ou assurez-vous de disposer des clés de récupération avant sortie/renommage. Les opérations de domaine ne chiffrent pas la machine, mais un changement de SID/nom peut déclencher des protections.

Résumé opérationnel

Validez DNS/heure/réseau → tentez Test-ComputerSecureChannel -Repair → sinon basculez en Workgroup puis rejoignez le domaine avec un compte de domaine → contrôlez via nltest, gpupdate et une connexion utilisateur du domaine.

Annexes – scripts et aides-mémoire

Script de test local

$domain = "contoso.local"
$dc = (nltest /dsgetdc:$domain | Select-String "Address").ToString()
Write-Host "DC détecté:" $dc

if (-not (Test-Connection -ComputerName (\$dc -replace ".\*: ","") -Count 1 -Quiet)) {
Write-Warning "DC injoignable. Vérifiez VPN/DNS/pare-feu."
} else {
Write-Host "Vérification du canal sécurisé…"
if (-not (Test-ComputerSecureChannel)) {
Test-ComputerSecureChannel -Repair -Credential (Get-Credential) | Out-Null
Restart-Computer -Force
} else {
Write-Host "Canal sécurisé OK."
}
}

Table d’aide rapide

ProblèmeCause fréquenteAction immédiateValidation
« No logon server »DNS externes, pas de DCPointer DNS vers DC, vérifier VPNnltest /dsgetdc OK
« Trust relationship »Secret machine désyncTest-ComputerSecureChannel -Repairnltest /sc_verify OK
Échec de jonction GUIIdentifiants locaux utilisésUtiliser compte du domaineInvite acceptée, redémarrage
Kerberos invalideHorloge décaléew32tm /resyncLogon OK

Avec cette procédure éprouvée, vous rétablissez rapidement la confiance poste–domaine, sécurisez vos flux Kerberos/Netlogon, et réduisez durablement les récurrences en normalisant DNS, temps et GPO.

Windows Server
Sommaire