Réparer ‘La relation de confiance entre la station de travail et le domaine principal a échoué’ – techsyncer

Une fois les problèmes les plus courants qui affectent les administrateurs système Windows sont établis, les ordinateurs du domaine Active Directory semblent tomber en panne. L’infâme erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué » est malheureusement trop fréquente.

Dans ce guide, vous allez apprendre tous les astuces que j’ai découvertes au cours de mes 20+ années de gestion d’Active Directory et comment les automatiser avec PowerShell.

Message d’erreur « La relation de confiance entre cette station de travail et le domaine principal a échoué«

Lorsqu’un domaine AD ne fait plus confiance à un ordinateur, c’est probablement parce que le mot de passe de l’ordinateur local ne correspond pas au mot de passe stocké dans Active Directory.

The Trust Relationship Between This Workstation and the Primary Domain Failed

Les deux mots de passe doivent être synchronisés pour qu’AD fasse confiance à un ordinateur. S’ils ne le sont pas, vous recevrez l’infâme message d’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué ».

Malheureusement, il n’y a jamais eu de solution unique que moi-même et d’autres administrateurs système avons trouvé qui fonctionne à 100% du temps. C’est pourquoi j’ai écrit ce guide.

Ce guide a pour but d’être un référentiel unique pour chaque moyen de résoudre définitivement ce problème et d’automatiser le processus avec PowerShell.

Mots de passe des comptes d’ordinateurs Active Directory

Lorsqu’un nouvel ordinateur est ajouté à l’Active Directory, un compte d’ordinateur est créé avec un mot de passe. Ce mot de passe est valide par défaut pendant 30 jours. Après 30 jours, il change automatiquement. Si le mot de passe change et que le mot de passe du client ne change pas, vous obtiendrez le message d’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué ».

Consultation des politiques existantes

Vous pouvez consulter la politique à l’échelle du domaine en ouvrant la console de gestion de la stratégie de groupe (GPMC). À l’intérieur de la GPMC, cliquez sur la Default Domain Policy, et accédez à Computer Configuration –> Windows Settings –> Security Settings > Local Policies > Security Options.

Une fois dans Security Options, recherchez la politique appelée Domain member: Maximum machine account password age.

Sur un ordinateur joint à l’AD, ouvrez regedit et accédez à la clé de registre HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters et trouvez la valeur MaximumPasswordAge comme indiqué ci-dessous.

Local Computer Account Password Age Registry Value

Pendant que vous y êtes, vous pouvez désactiver le changement de mot de passe local de l’ordinateur en réglant la valeur DisablePasswordChange sur 1.

Lorsque le compte d’ordinateur change, le mot de passe du compte local et du compte AD devrait changer ensemble. L’AD connaît l’actuel et l’ancien au cas où ils deviendraient désynchronisés pendant une courte période.

Le processus de changement de mot de passe du compte d’ordinateur

Lorsque les choses fonctionnent normalement, en utilisant le service Windows Netlogon, l’ordinateur initie automatiquement un changement de mot de passe. Cela se produit lors d’un redémarrage de l’ordinateur ou lorsque l’objet de l’ordinateur doit s’authentifier auprès d’AD.

En utilisant le service Windows Netlogon, l’ordinateur local lance une séquence de changement de mot de passe. L’ordinateur commence d’abord par initier un changement de mot de passe sur un contrôleur de domaine. Si cela réussit, il tente ensuite de modifier le mot de passe local pour correspondre à celui figurant dans la clé de registre HKLM\SECURITY\Policy\Secrets<hostname>.ACC.

Normalement, ce processus fonctionne parfaitement même si l’ordinateur est éteint ou hors ligne pendant plus de 30 jours car l’ordinateur local initie un changement de mot de passe.

Cependant, un problème survient lorsque:

l’ordinateur modifie le compte ordinateur AD mais est incapable de changer le mot de passe local
l’ordinateur est réimager sans exécuter Sysprep
le système d’exploitation est réinstallé et tente de s’authentifier avec l’ancien compte ordinateur AD activé
…et plus encore?

Si l’un des cas ci-dessus se produit, vous verrez le message d’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué ».

Vérification du problème

Une fois que vous savez que le problème existe, comment le reproduire ou du moins avoir une méthode pour déterminer quels ordinateurs sont concernés ? Vous pourriez essayer de vous connecter interactivement à chaque ordinateur, mais ce n’est pas évolutif et je ne veux pas me lever de mon bureau !

Construisons un script que nous pouvons exécuter localement et à distance pour déterminer quels ordinateurs du domaine ont ce problème et éradiquer définitivement le message d’erreur « La relation de confiance entre la station de travail et le domaine principal a échoué ».

Tout d’abord, étant donné que vous supposez que l’authentification du domaine ne fonctionne pas, vous devrez connaître un compte utilisateur local dans le groupe des administrateurs. J’espère que vous connaissez le mot de passe de votre administrateur local!

nltest (outil en ligne de commande)

Nltest est un outil en ligne de commande « old-school » qui teste la relation de confiance pour un ordinateur. Cet outil est installé lorsque vous installez RSAT ou est directement disponible sur un contrôleur de domaine.

Vous pouvez vérifier une relation de confiance sur un ordinateur lorsque vous êtes connecté à l’ordinateur en exécutant:

> nltest /sc_verify:<your domain FQDN>

AVERTISSEMENT: Cette méthode n’est pas recommandée car nltest ne fonctionne que dans le contexte utilisateur dans lequel il a été lancé. Si l’ordinateur a une relation de confiance rompue et que vous êtes connecté en tant qu’utilisateur local, il tentera de se connecter au domaine en utilisant les informations d’identification de l’utilisateur local. Cela entraîne une erreur d’accès refusé.

netdom (outil en ligne de commande)

netdom est un autre outil en ligne de commande que vous pouvez utiliser pour vérifier une relation de confiance. Cet outil est également installé lorsque vous installez RSAT ou est disponible directement sur un contrôleur de domaine.

Vous pouvez vérifier une confiance en utilisant netdom verify en fournissant :

le nom de l’ordinateur à vérifier
le FQDN du domaine
le nom d’utilisateur pour authentifier la demande
le mot de passe du compte utilisateur

Voici un exemple :

> netdom verify MYCOMPUTER /Domain:domain.local /UserO:abertram /PasswordO:*

En fournissant la valeur de * au paramètre PasswordO, netdom demandera le mot de passe.

Test-ComputerSecureChannel (PowerShell)

Une des meilleures façons de résoudre le problème « la relation de confiance entre cette station de travail et le domaine principal a échoué » est d’utiliser la cmdlet Test-ComputerSecureChannel. Cette cmdlet PowerShell est fournie avec Windows 10 et est plus facile à utiliser.

Le cmdlet Test-ComputerSecureChannel fonctionne localement sur un ordinateur Windows 10. Lorsque vous êtes connecté à l’ordinateur de manière interactive, ouvrez une console PowerShell et exécutez Test-ComputerSecureChannel sans aucun paramètre. Il renverra soit True soit False selon que la confiance est valide.

PS51> Test-ComputerSecureChannel
True

Vous pouvez également spécifier un contrôleur de domaine particulier pour confirmer que les mots de passe sont synchronisés en utilisant le paramètre Server.

PS51> Test-ComputerSecureChannel -Server 'DC.domain.local'
False

Ce cmdlet est simple à utiliser et comporte une option Repair, mais nous réservons une démonstration de cela pour la section de réparation.

Si vous connaissez le mot de passe de l’administrateur local de ces ordinateurs que vous souhaitez vérifier et que l’Accès distant PowerShell est activé sur eux, vous pouvez également utiliser le cmdlet Invoke-Command. En utilisant le cmdlet Invoke-Command, vous pouvez exécuter Test-ComputerSecureChannel à distance sur un ou plusieurs ordinateurs à la fois.

PS51> Invoke-Command -ComputerName PC1, PC2, PC3 -ScriptBlock { Test-ComputerSecureChannel }

Vérification des relations de confiance en vrac

Maintenant que vous savez comment vérifier à distance une relation de confiance, voici un extrait de code que vous pouvez utiliser pour vérifier tous vos ordinateurs AD ! Dans ce script, je teste d’abord pour m’assurer que l’ordinateur est en ligne. Sinon, il renverra Hors ligne. Sinon, il exécutera Test-ComputerSecureChannel sur chaque ordinateur et renverra soit True soit False.

Testing trust relationships in bulk
$localCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $trustStatus = Invoke-Command -ComputerName $_.Name -ScriptBlock { Test-ComputerSecureChannel } -Credential $localCredential
       $output.Status = $trustStatus
   }
 
   [pscustomobject]$output
 
})

Savoir et comprendre le problème est la première étape, mais comment le résoudre ? Vous savez maintenant que vous devez obtenir le compte d’ordinateur stocké sur l’ordinateur local identique au compte d’ordinateur stocké dans AD.

Il existe de nombreuses « solutions » disponibles pour le problème « la relation de confiance entre cette station de travail et le domaine principal a échoué ». Ces solutions peuvent être réalisées via l’interface graphique, via PowerShell ou via des outils en ligne de commande à l’ancienne.

Réinitialiser le mot de passe du compte informatique dans AD
Réinitialiser le mot de passe du compte informatique local
Désassocier puis réassocier l’ordinateur Windows
Supprimer complètement le compte informatique et réassocier l’ordinateur Windows

C’est beaucoup d’options ! Dans ce guide, nous allons nous concentrer sur la résolution de ce problème avec PowerShell et des outils en ligne de commande (pour l’exhaustivité). Si vous n’utilisez pas déjà PowerShell, vous devriez le faire !

Résolution du problème : Réinitialisation des mots de passe des ordinateurs

netdom (Outil en ligne de commande)

A trust can be repaired and the “the trust relationship between this workstation and the primary domain failed” error message can be eliminated by using the old-school netdom command-line tool. If you’re logged into the computer locally as an administrative user, you can run netdom resetpwd to initiate the password reset sequence as shown below.

Dans cet exemple :

DC est le nom du contrôleur de domaine
abertram est le nom du compte utilisateur Active Directory avec les droits pour réinitialiser le compte informatique
* est un espace réservé pour le mot de passe du compte utilisateur qui demandera le mot de passe.

> netdom resetpwd /s:DC /ud:abertram /pd:*

Reset-ComputerMachinePassword (PowerShell)

Une des meilleures façons de rétablir une relation de confiance est d’utiliser la cmdlet Reset-ComputerMachinePassword. Cette cmdlet s’exécute sur l’ordinateur local et initiera une séquence de réinitialisation du mot de passe. Sa syntaxe ne pourrait pas être plus simple.

PS51> Reset-ComputerMachinePassword

Si vous souhaitez spécifier un contrôleur de domaine particulier à réinitialiser, vous pouvez le faire en utilisant le paramètre Server avec une option de connexion (cela se fera par défaut avec l’utilisateur local).

L’exemple ci-dessous demandera un nom d’utilisateur et un mot de passe AD et tentera de réinitialiser le mot de passe sur l’ordinateur local et le contrôleur de domaine DC.

PS51> Reset-ComputerMachinePassword -Server DC -Credential (Get-Credential)

Cela peut également être exécuté à distance en utilisant Invoke-Command si PowerShell Remoting est disponible sur l’ordinateur. Ci-dessous, je récupère le nom d’utilisateur et le mot de passe du compte administrateur local sur l’ordinateur. Je récupère également les informations d’identification qui ont le droit de réinitialiser le mot de passe du compte AD de cet ordinateur. Ensuite, je passe $domainCredential dans la session à distance en utilisant la construction $using.

$localAdminCredential = Get-Credential
$domainCredential = Get-Credential

PS51> Invoke-Command -Computername MYCOMPUTER -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }

Notez que cela fonctionne également même si le compte de l’ordinateur a été supprimé de l’Active Directory. Créez un compte d’ordinateur avec le même nom et Reset-ComputerMachinePassword garantira que le mot de passe est synchronisé.

Réinitialisation des mots de passe des comptes d’ordinateur locaux en masse

Vous voulez vous occuper de l’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué » sur plusieurs ordinateurs à la fois ? Pas de problème. En utilisant une boucle foreach pratique, nous pouvons également exécuter Reset-ComputerMachinePassword en masse.

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $pwChangeOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }
       $output.PasswordChangeOutput = $pwChangeOutput
   }
 
   [pscustomobject]$output
 
})

Test-ComputerSecureChannel -Repair (PowerShell)

Une autre façon d’initier le processus de changement de mot de passe est d’exécuter Test-ComputerSecureChannel mais cette fois en utilisant l’option Réparer. D’après ce que je peux voir, ce processus est identique à l’utilisation de Reset-ComputerMachinePassword. Sur la console de l’ordinateur, utilisez le paramètre Réparer et le paramètre Identifiant.

PS51> Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Assurez-vous toujours d’utiliser le paramètre Identifiant ici. Si vous ne le faites pas, de la même manière que l’utilitaire nltest, il essaiera d’utiliser le compte local et cela ne fonctionnera pas.

Réparer les relations de confiance en masse

Insérez cette commande dans la boucle foreach pratique que nous avons utilisée et le tour est joué !

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
 
@(Get-AdComputer -Filter *).foreach({
 
   $output = @{ ComputerName = $_.Name }
 
   if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
   } else {
       $repairOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Test-ComputerSecureChannel -Repair -Credential $using:domainCredential }
       $output.RepairOutput = $repairOutput
   }
 
   [pscustomobject]$output
 
})

Réparer le problème : rejoindre le domaine

Si la réinitialisation des mots de passe des comptes d’ordinateur ne fonctionne pas pour vous, il y a toujours l’option nucléaire. Vous pouvez réintégrer un ordinateur au domaine Active Directory. Bien que cela ne soit pas nécessaire tout le temps, il y a eu des moments où j’ai dû utiliser cette approche.

Notez que j’ai entendu dire que le fait de se désinscrire n’est pas nécessaire. Vous pourriez peut-être vous en sortir en forçant simplement une nouvelle adhésion. Votre expérience peut varier.

Vous pouvez :

vous connecter à l’ordinateur via un compte administrateur local
aller dans Propriétés du système
cliquer sur Modifier
le définir sur un groupe de travail
redémarrer
le rétablir dans le domaine

Remarquez comment je mentionne pouvez. Ne faites pas cela. C’est une perte de temps lorsque vous pouvez l’automatiser avec PowerShell.

Il existe deux façons que j’ai trouvées pour utiliser PowerShell afin de quitter un domaine et de rejoindre un domaine.

En utilisant CIM

, vous pouvez rejoindre un domaine avec PowerShell (et le quitter) en utilisant la classe CIM Win32_ComputerSystem. Cette classe dispose de deux méthodes qui vous permettent de quitter et de rejoindre un ordinateur à un domaine appelées UnJoinDomainOrWorkgroup() et JoinDomainOrWorkGroup.

Comme il s’agit de CIM, vous pouvez exécuter cela aussi facilement à distance que localement. Comme je suppose que vous préféreriez exécuter cela à distance depuis le confort de votre bureau, voici un extrait de code qui le fait.

Adieu l’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué »!

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'UnjoinDomainOrWorkGroup'
    Arguments = @{ FUnjoinOptions=0;Username="Administrator";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Remarquez le paramètre FUnjoinOptions ci-dessus. J’ai choisi de spécifier 4 ici. Cela effectue le comportement par défaut lorsqu’on quitte manuellement un ordinateur. Cette option désactive le compte d’ordinateur dans Active Directory (si elle peut en trouver un). Si vous préférez ne pas avoir ce comportement, vous pouvez utiliser l’option 0 ici.

Une fois l’ordinateur déconnecté, vous pouvez ensuite le rejoindre au domaine en utilisant la méthode JoinDomainOrWorkGroup().

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'JoinDomainOrWorkGroup'
    Arguments = @{ FJoinOptions=3;Name=mydomain.local;Username="mydomain\domainuser";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Remarquez le paramètre FJoinOptions ci-dessus. J’ai choisi de spécifier 3 ici. Cela effectue le comportement par défaut lors de l’ajout manuel d’un ordinateur. Cette option crée un compte d’ordinateur AD. Vous pouvez trouver quelques autres options comme l’ajout à une OU spécifique via la documentation JoinDomainOrWorkgroup.

CONSEIL : Vous pouvez également dissocier et réassocier plusieurs ordinateurs à la fois via cette méthode en spécifiant plusieurs ordinateurs via le paramètre ComputerName sur Get-CimInstance.

Utilisation des cmdlets Remove-Computer et Add-Computer

Vous pouvez également utiliser les cmdlets PowerShell intégrés pour dissocier et joindre un ordinateur à un domaine avec PowerShell. Vous pouvez utiliser les cmdlets Remove-Computer et Add-Computer.

Pour désolidariser un ordinateur avec PowerShell, connectez-vous à la console de l’ordinateur et utilisez la cmdlet Remove-Computer. Fournissez les informations d’identification du domaine avec les autorisations pour désolidariser l’ordinateur. Vous pouvez également spécifier le paramètre Restart pour forcer un redémarrage après la désolidarisation et Force pour éviter la demande de confirmation.

PS51> Remove-Computer -UnjoinDomaincredential (Get-Credential) -Restart -Force

Une fois l’ordinateur redémarré, vous pouvez utiliser la cmdlet Add-Computer pour joindre l’ordinateur au domaine avec PowerShell. Vous pouvez utiliser la cmdlet Add-Computer à distance en fournissant le paramètre ComputerName. Vous utiliserez également les informations d’identification de l’utilisateur local pour établir la connexion et les informations d’identification du domaine pour vous authentifier auprès du domaine.

Quand il revient en ligne, espérons que vous ne recevrez plus le message d’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué. »

$localCredential = Get-Credential
$domainCredential = Get-Credential

Add-Computer -ComputerName PITA -LocalCredential $localCredential -DomainName domain.local -Credential $domainCredential -Restart -Force

Désolidarisation et réintégration automatiques du domaine

Parce que j’ai dû effectuer ce processus beaucoup trop de fois, j’ai créé un script PowerShell qui fait tout pour vous. Si vous lui fournissez le nom de l’ordinateur, il fera :

Désolidariser l’ordinateur
Redémarrer et attendre qu’il revienne en ligne
Joindre l’ordinateur
Redémarrer et attendre qu’il revienne en ligne

Vous pouvez essayer ce script via GitHub.

Résumé

Vous devriez maintenant avoir une compréhension complète du problème et de multiples solutions au fameux message d’erreur « La relation de confiance entre cette station de travail et le domaine principal a échoué« . J’espère que ce guide vous a fourni quelques idées et vous a permis de trouver des solutions par vous-même au problème des ordinateurs tombant du domaine !

Lecture complémentaire

Assurez-vous de consulter d’autres articles connexes !