L’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué » signifie que l’ordinateur ne peut pas accéder à un réseau car il est hors ligne ou qu’il a perdu son adhésion au domaine Active Directory (AD). Ce guide vous aidera à comprendre ce qui se passe en coulisses lorsque cette erreur se produit, et nous passerons en revue différentes méthodes pour résoudre ce problème.
Comme vous le verrez, il existe plusieurs solutions possibles pour corriger l’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué ». Notamment, il y en a une qui est plus rapide que la méthode traditionnelle – « déconnexion du domaine, redémarrage, réadhésion au domaine, redémarrage… ». Commençons !
Comprendre l’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué »
Le message d’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué » est certainement l’un des plus ennuyeux que rencontrent les professionnels de l’informatique lorsqu’ils travaillent avec des appareils rejoignant Active Directory. Il semble surgir de nulle part juste pour mettre un frein à vos tâches quotidiennes pour accomplir des choses.
Comment pouvez-vous rencontrer cette erreur ?
Lorsque vous rejoignez une station de travail à un domaine Active Directory, un compte informatique est créé dans AD. Et tout comme avec un compte utilisateur, ce compte informatique a un mot de passe, valable pendant 30 jours avant d’être mis à jour.
Note – Vous avez la possibilité de modifier le registre pour changer l’attribut ‘âge maximal du mot de passe du compte machine’. Si vous le souhaitez, ouvrez Regedit.exe et modifiez la clé suivante :
hklm-SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge
À chaque fois qu’un ordinateur se « connecte » à Active Directory (lors d’un redémarrage, et avant la connexion d’un utilisateur), il vérifie son mot de passe de compte informatique avec le contrôleur de domaine (DC) le plus proche :
- S’ils sont synchronisés, l’ordinateur s’authentifie avec succès à AD et la vie continue.
- Si l’appareil n’a pas de connexion réseau à AD, une période de grâce pouvant aller jusqu’à 30 jours est autorisée.
Le scénario où vous rencontrez l’erreur “trust relationship between this workstation and the primary domain failed” est lorsque qu’un utilisateur de domaine tente de se connecter à la station de travail (et au domaine). Si l’utilisateur s’est déjà connecté et que son mot de passe AD est mis en cache sur l’appareil, il pourra se connecter pendant cette période de grâce. Cependant, si un utilisateur qui n’a pas encore essayé de se connecter à l’appareil tente de le faire et que la confiance entre l’appareil et AD est indisponible, vous obtiendrez cette erreur exacte.
Pourquoi cette erreur se produit-elle?
Cette erreur de “trust relationship between this workstation and the primary domain failed” se produit lorsque l’ordinateur n’est plus approuvé dans le domaine. Le canal sécurisé entre la station de travail et Active Directory est manquant. Le mot de passe de l’ordinateur local n’est pas coordonné avec le mot de passe de l’ordinateur dans votre Active Directory.
Il existe quelques scénarios courants où cette erreur peut se produire, voici quelques exemples :
- Si vous réinstallez Windows.
- Si vous réinitialisez Windows.
- Si vous restaurez l’état d’une machine virtuelle.
- Si vous remplacez des composants matériels plus importants dans un appareil, etc.
- Si vous clonez un appareil sans utiliser d’abord Sysprep.
Il existe plusieurs autres raisons sous-jacentes qui pourraient conduire à cette erreur. Problèmes de connexion réseau, un problème avec votre infrastructure DNS, et même des problèmes avec le câble réseau de votre appareil! L’important est de prendre les choses lentement, de ne faire AUCUNE hypothèse, et d’utiliser ce guide pour suivre chaque étape de ce diagramme de dépannage pour résoudre votre problème.
Comment résoudre l’erreur « la relation de confiance entre ce poste de travail et le domaine principal a échoué »
Il existe quelques méthodes que vous pouvez utiliser pour corriger l’erreur « la relation de confiance entre cette station de travail et le domaine principal a échoué ». Ce que vous devez faire ici, c’est résoudre la relation de confiance entre votre appareil et Active Directory. Commençons par examiner quelques notions fondamentales que vous pourriez occasionnellement négliger en raison de contraintes de temps.
Vérification de la relation de confiance avec la commande Test-ComputerSecureChannel
Eh bien, regardez ça ! Une précieuse perle de PowerShell pour aider à réparer l’état de la relation de confiance de votre appareil avec Active Directory. J’ai une VM Windows 11 dans mon environnement de laboratoire Hyper-V Active Directory Windows Server 2022. Utilisons la cmdlet Test-ComputerSecureChannel pour vérifier notre connexion à AD.
Test-ComputerSecureChannel -verbose
Ici, le « True » dans la sortie signifie que tout va bien. ?
Vérification des paramètres DHCP
Vous voudrez exécuter ipconfig dans une invite de commandes pour vous assurer que l’adresse IP de votre poste de travail est soit dans le même sous-réseau que celui de votre contrôleur de domaine (DC) soit dispose d’une route vers ces sous-réseaux. Vous pouvez également essayer de pinguer l’un de vos DCs par son nom ou nom de domaine complet (FQDN).
Si cela ne fonctionne pas ou n’aboutit pas, vous avez un problème de connectivité réseau plus basique. Vous devrez effectuer un dépannage essentiel dans ce domaine en premier lieu avant de continuer.
Vous pouvez également exécuter les commandes ipconfig /release et ipconfig /renew pour libérer votre adresse IP attribuée par DHCP, et soit la renouveler soit en obtenir une nouvelle. Parfois, ces étapes résolvent des problèmes de connexion réseau assez bizarres. Allez-y et essayez.
Réinitialisation du mot de passe du compte machine
Plongeons directement dans les méthodes plus efficaces et moins chronophages pour résoudre notre problème. L’objectif ici est de réinitialiser le mot de passe d’un compte ordinateur. Je vous montrerai plus tard les étapes pour utiliser l’interface graphique dans Windows pour dissocier, réassocier, redémarrer, etc.
Mais ne serait-ce pas agréable d’éviter tous ces redémarrages ? Eh bien, oui, je suis sûr que ce serait le cas. Surtout si vous utilisez un ordinateur plus lent.
En utilisant l’outil en ligne de commande netdom resetpwd
Le premier outil en ligne de commande que nous utiliserons s’appelle netdom. Vous pouvez l’installer sur une station de travail en installant les outils d’administration du serveur distant (RSAT), spécifiquement l’option « Outils des services de domaine Active Directory et des services d’annuaire léger« . Vous pouvez apprendre les bases de l’installation des outils RSAT en lisant mon article précédent sur le sujet.
Ouvrez une invite de commande administratif et utilisez la commande suivante netdom resetpwd :
netdom resetpwd /Server:WS16-DC1 /UserD:administrator /passwordD:<em>password</em>
Succès ! Le mot de passe du compte machine pour la machine locale a été réinitialisé avec succès, et vous n’avez même pas besoin de redémarrer. Vous pouvez simplement vous déconnecter puis vous reconnecter avec un compte utilisateur de domaine et vous devriez être bon.
En utilisant la commande cmdlet Reset-ComputerMachinePassword
Un autre outil dans votre boîte à outils PowerShell est la commande Reset-ComputerMachinePassword. Comme netdom, cette commande changera / mettra à jour le mot de passe du compte ordinateur dans l’Active Directory.
Allez-y et ouvrez une console PowerShell. La structure de commande de base est la suivante :
Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin
Ainsi, dans notre cas, je vais exécuter cette commande :
Reset-ComputerMachinePassword -Server WS16-DC1 -Credential Administrator
Pas de nouvelles, bonnes nouvelles. ?
Utilisation de l’outil Active Directory User and Computers
Il y a une démarche très simple que vous pouvez suivre en utilisant les Utilisateurs et ordinateurs Active Directory (ADUC) pour effectuer la même fonction que les deux méthodes en ligne de commande précédentes. Localisez simplement votre poste de travail dans votre répertoire, faites un clic droit sur l’objet de l’ordinateur, et cliquez sur ‘Réinitialiser le compte’.
Et voilà, le compte ordinateur a été réinitialisé.
Rejoignez votre machine au domaine Active Directory
D’accord, je garde la méthode traditionnelle, un peu ‘non robuste’, pour la fin afin de corriger l’erreur « La relation de confiance entre cette station de travail et le domaine principal a échoué » – ma recommandation est d’utiliser les outils en ligne de commande car ils sont plus efficaces, plus rapides et accomplissent simplement le travail de manière plus fiable. Vous n’avez pas à vous soucier des problèmes potentiels avec les profils locaux, les problèmes de connexion réseau du côté de la station de travail et d’autres problèmes généraux de Windows.
De toute façon, pour être complet, permettez-moi de vous montrer une autre méthode pour reconnecter votre machine au domaine Active Directory.
Utilisation des cmdlets Remove-Computer et Add-Computer
Il semblerait que je retienne l’ancienne méthode GUI pour une raison. 😏 Sortant de nulle part à la dernière seconde pour nous donner l’avantage tactique. Nous pouvons utiliser PowerShell, encore une fois, pour atteindre notre objectif. Nous pouvons utiliser les cmdlets Remove-Computer et Add-Computer.
Remarque – Assurez-vous de connaître les identifiants d’un compte administrateur local de l’appareil que vous utilisez. Vous en aurez besoin pour vous connecter après avoir dissocier la station de travail et redémarrer.
Voici le cmdlet Remove-Computer que vous devez utiliser pour retirer l’ordinateur du domaine et le redémarrer.
Remove-Computer -UnJoinDomaincredential reinders.local\mreinders -PassThru -Verbose -Restart
Ok. Après seulement quelques secondes, le redémarrage s’est produit. Maintenant, après m’être connecté avec un administrateur local, je peux utiliser le cmdlet ‘Add-Computer‘ pour rejoindre à nouveau le domaine.
Add-Computer -DomainName reinders.local -Passthru -Verbose -Restart
Encore une opération TRÈS rapide et un redémarrage ! Et nous voilà de retour dans les affaires.
En utilisant l’interface graphique et un compte Administrateur de domaine
Eh bien, je suppose que je peux vous montrer la méthode traditionnelle, mais efficace pour résoudre cette erreur. Nous allons suivre la procédure d’utilisation de l’interface graphique de Windows sur le poste de travail pour désolidariser notre appareil du domaine Active Directory et le rejoindre en mode groupe de travail, redémarrer, puis réintégrer notre appareil dans AD, redémarrer à nouveau, puis la mission devrait être accomplie.
Tout d’abord, cliquez sur Démarrer -> Paramètres -> Comptes -> Accès au travail ou à l’école. Cliquez sur la flèche déroulante à droite où s’affiche le nom de domaine DNS AD et cliquez sur Déconnecter. Cliquez sur Oui.
Cliquez sur le bouton Déconnecter sur la fenêtre contextuelle suivante.
Ici, confirmez les informations d’identification d’un compte local avec lequel vous pourrez vous connecter une fois que votre poste de travail aura été retiré du domaine.
Cette étape est importante – si vous n’avez pas accès à un compte local et un mot de passe, vous devrez réinstaller Windows ou réimager votre appareil.
Une fois que vous avez terminé, cliquez sur Redémarrer maintenant pour redémarrer votre machine.
À ce stade, je me suis connecté avec mon compte local ‘Michael’. J’ai ensuite procédé de la même manière : Démarrer -> Paramètres -> Comptes -> Accès au travail ou à l’école.
Ici, cliquez sur le bouton Connecter à côté de ‘Ajouter un compte de travail ou d’école.’
Choisissez le dernier lien en bas : Joindre cet appareil à un domaine Active Directory local.
Entrez le nom de domaine complet (FQDN) de votre domaine Active Directory et cliquez sur Suivant.
Si le domaine est correctement contacté (sinon, vous pouvez consulter mon post pour aider dans votre dépannage), vous serez invité à vous connecter avec un compte de domaine disposant des autorisations Administrateurs de domaine ou équivalentes.
Ici, je vais suivre l’étape peu courante d’ajouter mon compte AD ‘mreinders’ au groupe Administrateurs local. Cela est à des fins de laboratoire uniquement et n’est pas une meilleure pratique en termes de sécurité.
Cliquez sur Redémarrer maintenant, connectez-vous avec votre compte utilisateur du domaine, et c’est fait !
Conclusion
I hope this post helps you in troubleshooting the root cause of the dreaded “trust relationship between this workstation and the primary domain failed” error message. Like I said, this seems to just crop up at the worst possible time. But, that’s IT. There are many ways to resolve issues in Windows and general Systems Engineering. Thankfully, you have a respectable number here to get your job back on track!
Source:
https://petri.com/trust-relationship-between-this-workstation-and-the-primary-domain-failed-error/