20 Fixes for “Trust Relationship between This Workstation and the Primary Domain Failed” Error

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.

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.

Causes for Trust Relationship between This Workstation and the Primary Domain Failed

Fixes for Trust Relationship between This Workstation and the Primary Domain Failed

There 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 Date

The 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:

1. Open the Group Policy Management Editor.
2. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy.
3. Double-click on Maximum tolerance for computer clock synchronization.
   
4. Increase the time and click OK.

Modify Domain Name

One 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:

1. Press Win + R to open Run.
2. Enter sysdm.cpl to load the System Properties.
3. Inside Computer Name, select Change.
   
4. Add or remove the suffix (such as .local, .net, etc.) on the Domain name and click OK.

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 Domain

Another 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:

1. Open System Properties and go to Computer Name.
2. Select Change.
3. Check Workgroup and enter any name you want.
   
4. Click OK and then OK again.
5. Restart your PC and go through the same steps till you reach Computer Name/Domain Changes.
6. This time, check Domain and type the Domain name.
7. Click OK and enter the credentials.

Restart your computer and check if the issue remains.

If it does, you need to clear the log files and try again.

1. First, disconnect your PC from the internet.
2. Delete the log files inside C:\ProgramData\Microsoft\Windows Server\Logs.
3. If you are using a third-party connector software to connect to the domain, uninstall it.
4. Rejoin your PC to the domain using the above steps.

Verify DHCP Configuration

Improper 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,

1. Open Run and enter dhcpmgmt.msc on the Domain Controller server.
2. Go to your server and expand IPv4 > Scope > Address Pool.
3. Check the Start and End IP Addresses.
4. Right-click on Scope and select Properties.
   
5. Change the Start and End IP Addresses as required.

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 Manager

You 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:

1. Open Run and enter control /name Microsoft.CredentialManager.
2. Select Windows Credentials > Add a Windows credential.
   
3. Enter the domain name, domain username and password and click OK.

Confirm to Active Directory Domain Services Port Requirements

The 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 Directory

If 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:

1. Open Run (Win + R).
2. Type powershell and press Ctrl + Shift + Enter. It loads the Elevated Windows PowerShell.
3. Enter the command $env:computername to get your hostname.
4. Then, type Get-ADComputer <Host Name> and press Enter to check if your computer exists on the AD. Make sure to use your own host name.
5. If it doesn’t, enter the following command while replacing the values depending on your situation:
   New-ADComputer -Name "Host Name" -SamAccountName "Host Name" -Path "OU=ApplicationServers,OU=ComputerAccounts,OU=Managed,DC=USER02,DC=COM

Test and Repair Computer Secure Channel

You 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:

1. Open Run (Win + R).
2. Type powershell and press Ctrl + Shift + Enter. It loads the Elevated Windows PowerShell.
3. Enter the command Test-ComputerSecureChannel - Verbose
4. If it finds any issues, run Test-ComputerSecureChannel -Repair
   

Restart your PC, log in to the domain user account and check if the issue persists.

Reset Credentials

If 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.

1. Open the Elevated Windows PowerShell on your local administrator account.
2. Enter the command $credential = Get-Credential
3. Type Reset-ComputerMachinePassword -Credential $credential and press Enter.

Restart your PC, log in to the domain user account and check if you still encounter this issue.

Enable Caching of Domain Credentials

Some 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:

1. Enter secpol.msc on Run.
2. Go to Security Settings > Local Policies > Security Options.
3. Double-click on Interactive logon: Number of previous logons to cache.
   
4. Set the logons cache to any number you want. The possible values range from 0 to 50.

You can also use the registry editor to make this change. To do so,

1. Open Run and enter regedit.
2. Navigate to Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.
3. Double-click on CashedLogonsCount and change the Value Data according to your preference.
   

Disable Startup Recovery

Windows 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:

1. Open Command Prompt as an admin.
2. Enter the following commands:
   • bcdedit /set recoveryenabled no
   • bcdedit /set bootstatuspolicy ignoreallfailures

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 Age

If 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:

1. Enter secpol.msc on Run.
2. Go to Security Settings > Local Policies > Security Options.
3. Double-click on Domain member: Maximum machine account password age.
4. Set the maximum age according to your need. You can set any value between 0 and 999.

You can also use the registry editor to make this change. To do so,

1. Open the Registry Editor by entering regedit on Run.
2. Navigate to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
3. Double-click on MaximumPasswordAge and change the Value Data according to your preference.

If you are using Provisioning Services to stream software form vDisks, you also need to change the password age from its console.

1. Open the Provisioning Server Console on the DC.
2. Open the Domain and expand Sites > Site > Servers.
3. Right-click on your server and select Properties.
4. Go to the Options tab.
5. Change the number of days and click Ok.
   

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 Controller

On 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

1. Open Active Directory Users and Computers.
2. Expand the domain and select Users.
3. Right-click on the user account you need to reset and select Reset Password.
   
4. Set up a new password and keep confirming till you are done.

Using Netdom Utility

1. Log in to the Windows server (Domain Controller) using your admin account.
2. Open the Elevated Command Prompt and enter the command: netdom resetpwd /s:<server> /ud:<domain\user> /pd:*

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

1. Open the Elevated Command Prompt on the Windows server.
2. Enter the command nltest /sc_change_pwd:<AD DS domain name> while replacing <AD DS domain name> with the name of the workstation.

Reset Computer Account

Another 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.

1. Open Run.
2. Enter dsa.msc to open the Active Directory User and Computers.
3. Go to your domain and expand Computers.
4. Right-click on the domain user’s computer and select Reset Account.
   
5. Click Yes and then OK.

Ask the domain computer’s user to restart their PC and log in using the domain account.

Check Domain Controller Health

It 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 SID

In 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,

1. Open Run and enter ntdsutil.
2. On the Ntdsutil CLI, enter security account management.
3. Enter connect to server <your server name>.
4. Enter the command check duplicate sid.
5. If there are duplicates, enter cleanup duplicate sid.
6. Enter quit twice to close the CLI.

After removing the duplicate SIDs, recreate the deleted accounts on the Active Directory.

Clean Up Server Metadata

If 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:

1. Open Run and enter ntdsutil.
2. On the Ntdsutil, enter metadata cleanup.
3. Enter remove selected server <server name> while replacing with the name of the server that you deleted.
   
4. Enter quit or q after the process completes to close the CLI.

Remove Lingering Objects and Enable Strict Replication Consistency

Lingering 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:

1. Open the Elevated Command Prompt on the server.
2. Enter the following commands:
   • repadmin /showrepl <ServerName>
   • repadmin /removelingeringobjects <ServerName> <ServerGUID> <DirectoryPartition> /advisory_mode
   • repadmin /removelingeringobjects <ServerName> <ServerGUID> <DirectoryPartition>
   • repadmin /regkey <DC_LIST> +strict

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 Controller

If 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:

1. Enter dsa.msc on Run.
2. Go to your domain and expand Domain Controllers.
3. Right-click on the domain and select Delete.
4. Check Delete this Domain Controller anyway and select Delete.
   

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.

Troubleshoot USN Rollback

This 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:

1. Demote the Domain Controller and shut down its server.
2. Clean up metadata if necessary.
3. Transfer FSMO roles to another Domain Controller, if applicable.
4. Restart the DC that experienced the rollback and transfer back the FSMO roles.

You can also restore the Domain Controller back to the state before the rollback if you have a system state backup.