Microsoft’s Active Directory services manages all users, controllers and other resources on the Windows server domain. It uses username, passwords and Secure Shell keys to identify the directory objects. Show
You will encounter the “Trust relationship between this workstation and the primary domain failed” error if the private secret key on the PC is different from that of the primary AD server. This results in the user not being able to access the Windows Server Domain. It usually happens because of duplicate computers or Domain Controller objects. However, it can also occur because of many other reasons. In this article, we explain all the possible reasons and how you can troubleshoot them.
Here are the potential causes for the “trust relationship between this workstation and the primary domain failed” issue:
Fixes for Trust Relationship between This Workstation and the Primary Domain FailedThere are many possible solutions you can perform from the local computer. But for others, you need to use the Domain Controller (DC) or a PC with RSAT tools. If you don’t have access to the DC, contact the system administrator to ask them to perform the relevant troubleshooting methods. Also, keep in mind that you need to log in to your local administrator (not domain user) account before performing the solutions from the workstations. Sync Time and DateThe first thing you should do is set correct date and time. If there’s more than 5 minutes of difference between the Domain Controller and the workstations, the users can’t authenticate to the DC services. To resolve this issue, you need to sync the times properly. Automatically syncing the time with the internet on the DC as well as your local machine should be enough in most cases. If there’s still some discrepancy, you need to adjust a Group Policy Object (GPO) on the Domain Controller. The process is as follows:
Modify Domain NameOne possible quick fix is to modify the domain name from FQDN to NETBIOS name. This refreshes your workstation on the domain without having to disconnect and reconnect it. However, it doesn’t work for public domains and only works within a NETBIOS Active Directory. Changing the domain name from NETBIOS name to FQDN is also a good solution if you are connected to a public domain and there are many servers with the same domain name. Adding the suffix helps you connect to the exact domain you want. Here are the necessary steps for this method:
Restart your PC and check if the issue reoccurs. If it does, or you encounter other errors, revert the domain name and move on to the successive solutions. Rejoin to DomainAnother way to resolve this issue is to unjoin your computer to the Domain and rejoin it again. Doing so removes any previous credentials your PC had stored and allows you to store the valid secret key after rejoining. Here’s how you can rejoin your workstation to the Domain:
Restart your computer and check if the issue remains. If it does, you need to clear the log files and try again.
Verify DHCP ConfigurationImproper DHCP configuration can also cause this issue. You need to make sure that the DHCP allocates IP addresses that are within the scope of your domain server’s IP address. For instance, if your configured network is 10.0.0.1/24, the start and end IP addresses for the DHCP should be 10.0.0.x. To check and alter the DHCP configuration,
Then, open your router’s portal on a web browser and navigate to its DHCP settings. See if all the settings are correct and make the necessary changes. Save Domain Controller to Credential ManagerYou should also try saving the domain credentials to the credential manager. You will encounter the trust failed error when there any errors while manually entering the credentials. If you save the credentials to the Credential Manager, you will be able to enter the domain environment without having to enter your password every time. Follow the steps below to perform this solution:
Confirm to Active Directory Domain Services Port RequirementsThe trust relationship will also fail if the Firewall doesn’t have the proper ports open to allow the workstations to communicate with the Domain Controller. So you need to make sure all the relevant ports are open. You can refer to the Microsoft documentation on configuring a firewall for Active Directory domains and trusts to learn the necessary process. Recreate Computer Object on Active DirectoryIf the Active Directory has removed your machine, you can’t access the Domain even if your PC shows it is a part of the domain. So, you need to check if it is the case and if yes, recreate your computer on AD. Here’s how you can do so:
Test and Repair Computer Secure ChannelYou need to check if your workstation’s secret key is the same as that of your computer account in the Domain Controller. One way you can do so from the local machine is by using the Test-ComputerSecureChannel PowerShell cmdlet. This is the best solution if your issues is due to the presence of another host machine with the same name on the DC. Here are the necessary steps for the process:
Restart your PC, log in to the domain user account and check if the issue persists. Reset CredentialsIf the private credentials on your workstation is different from that of the AD Domain Controller, the most convenient fix is to reset your credentials. In this method, your system uses the cached domain credentials to re-establish the trust. You can use the Reset-ComputerMachinePassword cmdlet on Windows PowerShell for this purpose.
Restart your PC, log in to the domain user account and check if you still encounter this issue. Enable Caching of Domain CredentialsSome of the above methods use the Cached domain credentials to establish trust. So, they only work if you have cached credentials. Otherwise, the Domain Controller admin needs reset your local machine or its password. You should enable the caching process to make it easier to troubleshoot this issue in case it happens again in the future. Here’s how you can do so:
You can also use the registry editor to make this change. To do so,
Disable Startup RecoveryWindows has a recovery feature that automatically restores the system after a power failure. In such scenario, the automatic recovery may revert the domain’s secret key that is stored in your PC. So, you can enable the boot policy to ignore all such failures to disable the feature. Here’s how you can do so:
However, keep in mind that this feature is there for your system’s protection. So, we don’t recommend disabling it unless you have to. Change Machine Account Password AgeIf you have to keep the workstation away from the Domain Controller (i.e., avoid logging in to the domain) for long intervals, you will need to troubleshoot the trust issue every time. In such scenarios, it’s better extend the age of the password to prevent such issues. Here’s how you can do so:
You can also use the registry editor to make this change. To do so,
If you are using Provisioning Services to stream software form vDisks, you also need to change the password age from its console.
You can also disable the process of password change altogether by enabling the DisablePasswordChange registry value or Domain member: Disable machine account password changes group policy object. However, we don’t recommend this practice as it may compromise the your privacy. Change Machine Password From Domain ControllerOn the Domain Controller’s side, changing or resetting the password for the client workstations should fix the credential difference issue. There are many ways to do so, such as: Using Active Directory
Using Netdom Utility
Don’t forget to replace <server> and <domain\user> accordingly. Ask the domain user to restart their PC and log in to their domain account with a new password. Using Nltest Utility
Reset Computer AccountAnother possible way to resolve this issue by resetting the workstation from the Domain Controller. It provides the same effect as unjoining and rejoining the computer to the DC.
Ask the domain computer’s user to restart their PC and log in using the domain account. Check Domain Controller HealthIt is also possible for this error to occur die to issues with the Domain Controller itself. You can run the dcdiag command on the server’s CLI to check the Domain Controller’s health. The result of this command should point you to any potential issues with the DC. First, run dcdiag /fix and see if it helps. If not, apply the steps in the successive solutions depending on your problem. Remove Duplicate Domain Controller SIDIn normal cases, a domain will only have unique SIDs for its Domain Controller. However, in some scenario, it is possible for there to be duplicate SIDs. The trust relationship can fail in such cases if the workstation tries to connect to the wrong account. You need to check and remove the duplicate Domain Controller in such scenario. To do so,
After removing the duplicate SIDs, recreate the deleted accounts on the Active Directory. Clean Up Server MetadataIf you forcibly removed an Active Directory Domain Services without cleaning up its metadata and created another Domain with the same name, workstations attempting to connect to this domain will also experience this issue. There are many ways to clean up server metadata. But the easiest is to use the Ntdsutil command. Here are the necessary steps:
Remove Lingering Objects and Enable Strict Replication ConsistencyLingering objects are the objects that the Domain Controller admins have deleted on the controller. If the DC goes offline for a long time, it is possible for its Active Directory to retain the object other DCs have deleted. After the DC goes online, these lingering objects can also replicate to the other controllers, causing many issues, including the trust relationship failed error. You need to remove the lingering objects to resolve the issue. You should also enable Strict Replication Consistency to prevent the replication of lingering objects. Here’s how you can execute both processes:
The first three commands review and remove the lingering objects and the last command enables Strict Replication Consistency. You can also enable this value form inside the Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters registry path. Demote and Re-promote Domain ControllerIf the above methods do not resolve the issue on the Domain Controller, you need to demote and re-promote it to reset the controller. First, demote the Domain Controller using the steps below:
If you are on a Windows server earlier than 2008, you need to clean up the server metadata. On later versions, this process happens automatically if you are using this method. Note: If you want to demote the DC permanently, you need to use a different method. Please refer to the Microsoft documentation on Demoting Domain Controllers and Domains to learn the necessary steps. After that, run DCPromo (Domain Controller Promoter) and follow the on-screen instructions to re-promote the DC. Troubleshoot USN RollbackThis issue can also occur if you roll back a Windows Server DC with an image-based installation of the OS on the server. This issue is called a USN rollback and it causes the changes you make on one DC to not replicate on others. You can’t tell if any causative problems we mentioned in the previous sections occurred after a USN rollback. It is because the other DCs believe themselves to have the most updated database. So they don’t update the passwords that originate from the rolled-back DC. You can check if a USN rollback has occurred from the Dsa Not Writable registry entry inside Computer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters. If it shows 4 or 0x4, it indicates the USN rollback. To troubleshoot this issue, You need to perform the following operations:
You can also restore the Domain Controller back to the state before the rollback if you have a system state backup. How do you fix trust relationship between workstation and primary domain failed?Resolution. Use a local administrator account to log on to the computer.. Select Start, press and hold (or right-click) Computer > Properties.. Select Change settings next to the computer name.. On the Computer Name tab, select Change.. Under the Member of heading, select Workgroup, type a workgroup name, and then select OK.. What causes the trust relationship between this workstation and the primary domain failed?“The trust relationship between this workstation and the primary domain failed” Error Message. When an AD domain no longer trusts a computer, chances are it's because the password the local computer has does not match the password stored in Active Directory. The two passwords must be in sync for AD to trust a computer.
How do you fix trust relationship between workstation and domain without rejoining?How to fix trust relationship between workstation and primary domain failed without rejoin domain. Remove network connection (unplug ethernet cable).. Login with domain credentials or local administrator.. Re-Add network (Plug-in Ethernet cable).. Open PowerShell cmdlet Run as Administrator.. How do I refresh my domain connection?There are a couple of ways do this:. In AD right-click the computer and select Reset Account. ... . In an elevated command prompt type: dsmod computer "ComputerDN" -reset. ... . In an elevated command prompt type: netdom reset MachineName /domain:DomainName /usero:UserName /passwordo:Password.. |