In this article, we’ll discuss the causes of the Trust relationship failed error and the ways to fix the issue. This guide covers possible solutions to restore a secure channel and trust relationships between the workstation and the primary Active Directory domain.
What does Trust relationship Failed error look like when you face it?
In what cases can you face this error? For example, when a user tries to log in to a workstation or server with domain account credentials. After entering a domain user account and password, a window appears (with an error message):
The trust relationship between this workstation and the primary domain failed
Or the error looks like this:
The security database on the server does not have a computer account for this workstation trust relationship
This error indicates that this computer is no longer trusted. The local computer’s password doesn’t match this computer’s object password stored in the AD database.
What is the Cause of Trust Relationship Failed Error?
A trust relationship may fail if the computer tries to authenticate on a domain with an invalid password. Typically, this occurs when:
- After reinstalling Windows;
- The computer system state was restored from an image backup (or SystemState), Virtual machine snapshot;
- Performing computer cloning without running the Sysprep,
- Someone manually reset your computer’s domain account;
- Your computer account object has been removed from Active Directory Domain Services (AD DS)
- Someone accidentally adds a computer with the same hostname to the domain;
- Your computer’s local time is offset by more than 5 minutes from the authenticating domain controller;
- Your domain controllers are having replication problems — the new computer account password has not been synchronized with the domain controller you use for authentication (Logon server). Check AD replication with repadmin tool.
In this case, the current value of the password on the local computer and the password stored for a computer object in the AD domain will be different.
How to fix Trust Relationship Failed error?
Let’s try to understand how to fix it. Below you will find steps to get rid of Trust relationship between primary domain failed error.
Check Secure Channel Between Workstation and the Primary Domain
You can verify if the computer local password is synced with the computer account password on the domain controlled. To do this, log on to the computer under the local administrator (!!!) account, start the PowerShell console, and run the Test-ComputerSecureChannel cmdlet. You can use a simple form:
Or you can add –Verbose switch parameter:
VERBOSE: Performing the operation “Test-ComputerSecureChannel” on target “Compname1”. True VERBOSE: The secure channel between the local computer and the domain theitbros.com is in good condition.
Hint. If you are unable to log into your computer using a an Active Directory user account, try temporarily disconnecting the network cable. In this case, you will be able to log on to the computer under cached credentials of AD user. Re-plug the network cable after logging in with cached credentials.
If this computer-to-domain trust relationship fails, you will receive an error:
The secure channel relationship between the local computer and domain theitbros.com is broken.
This means that to repair trust, you need to make sure that your computer account has not been removed from Active Directory and then reset its password.
Note. If the Test-ComputerSecureChannel command returns a “Network Path Not Found” error, check your network connectivity and ensure that the firewall is not blocking ports to access the domain controller.
Open the Active Directory users and computers snap-in (ADUC). Make sure the problematic computer account is present in the domain, and it’s not disabled.
Also, you can check if your computer account has not been removed from Active Directory using PowerShell:
#get the hostname on your device $env:computername #check for account on DC Get-ADComputer YourHostName
If the computer account doesn’t exist, create it on the domain controller using the command:
New-ADComputer -Name "YourHostName" -SamAccountName "YourHostName" -Path "OU=Computer,OU=London,OU=UK,DC=THEITBROS,DC=COM"
Repair Failed Trust Relationship without domain rejoining using PowerShell
You can reset the computer password using the PowerShell cmdlet Reset-ComputerMachinePassword.
The Reset-ComputerMachinePassword PowerShell cmdlet changes the password of the account that computer uses to authenticate to domain controllers. This cmdlet can be used to reset the local computer password.
Hint. The Reset-ComputerMachinePassword and Test-ComputerSecureChannel cmdlets are not available in PowerShell Core 6.0 and 7.x due to the use of unsupported APIs.
If you want to restore a trust relationship under a local Administrator, then run the elevated PowerShell console. Execute this command:
Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin
- Server — the FQDN name of any domain controller;
- Credential — domain user (with permission to add the computer to the domain) or domain admin account.
Reset-ComputerMachinePassword -Server lon-dc01 -Credential corp\dsmith
The credentials window will appear; you must type the domain account password.
The cmdlet doesn’t display any messages on success, so just re-login under a domain account. No reboot is required.
If you received the error The RPC server is unavailable 0x800706ba or An Active Directory Domain Controller (AD DC) for the domain could not be contacted, then try to run the Reset-ComputerMachinePassword cmdlet. Check DNS settings on your computer and DNS zones by following the guide An Active Directory domain controller cannot be contacted.
Tip. You can also repair a secure channel between the computer and Active Directory domain using PowerShell cmdlet Test-ComputerSecureChannel:Test-ComputerSecureChannel -Repair -Credential corpdsmith
Fixing Trust Relationship by domain rejoining
The most obvious old-school way to restore the trust relationship of your computer in the domain is:
- Reset local Admin password on the computer;
- Unjoin your computer from Domain to Workgroup (use the System Properties dialog box — sysdm.cpl);
- Reset Computer account in the domain using the ADUC console;
- Rejoin computer to the domain;
- Reboot again.
This method is the easiest, but not the fastest and most convenient — it requires multiple reboots. Also, we know cases when after the computer domain rejoining the local user profiles are not reconnecting correctly and users facing with User profile service failed the sign-in error.
Also, you can unjoin and rejoin your computer to the AD domain using WMI. Use the following PowerShell script:
$computer = Get-WmiObject Win32_ComputerSystem $computer.UnjoinDomainOrWorkGroup("AdminPassw0rd", "AdminAccount", 0) $computer.JoinDomainOrWorkGroup("DomainName", "AdminPassw0rd", "AdminAccount", $null, 3) Restart-Computer -Force
Tip. You can also fix this problem by deleting the computer account in Active Directory and recreating it without a password.
Also, you can use PowerShell to unjoin and join your computer to AD domain. Use the following built-in PowerShell cmdlets: Remove-Computer and Add-Computer.
To unjoin your device from the domain and force restart host, run the command:
Remove-Computer -UnjoinDomaincredential THEITBROS\AdminAccount -PassThru -Verbose –Restart
This assumes that you know the local user account credentials from the built-in Administrators group.
Then sign-in under the local administrator account and join your Windows host to Active Directory:
Add-Computer -DomainName THEITBROS -PassThru –Verbose -Restart
It is important to make sure the time difference between the domain controller and the client computer is less than 5 minutes. Read the article Configuring NTP on Windows using GPO to configure time synchronization in a domain.
Your computer cannot establish a trust relationship with a domain controller if the time on your device differs from the authenticating domain controller by more than 5 minutes.
Check the event viewer for event ID 130 from Time-Service source:
NtpClient was unable to set a domain peer to use as a time source because of failure in establishing a trust relationship between this computer and the ‘<DOMAIN>’ domain in order to securely synchronize time. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The trust relationship between this workstation and the primary domain failed. (0x800706FD)
Check your Window Time service source using the command:
w32tm.exe /query /source
If you are getting the time from the local CMOS (BIOS) clock, make sure the time on the computer matches the time on the domain controller.
Use the following guide to check and sync time with domain controller.
Using Netdom resetpwd to Fix Trust Relationship Failed without reboot
You can find Netdom utility in Windows Server since the 2008 version. It can be installed on the client’s PC as a part of the RSAT (Remote Server Administration Tools) package. The method is fast and efficient. To use it, login to the target system with the local Administrator account (by typing, “.Administrator” to the logon window), open the elevated cmd.exe prompt, and run the following command:
Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password
- Server — the name of any domain controller;
- UserD — username with domain admin or delegated privileges;
- PasswordD — admin password.
Netdom resetpwd /Server:lon-dc01 /UserD:dsmith /PasswordD:Str0NGestP@$
After the successful execution of this command, a reboot is not required. Just logout from a local account, and log in under domain credentials.
You can check a secure connection with the AD domain using Netdom with the following command:
Netdom Verify WK_Salary12 /Domain:corp.contoso.com /UserO:dsmith /PasswordO:*
This method does not always work. It’s not always possible to authorize on the domain controller under the administrator account from a computer with broken-trust relationship.
Repair Active Directory computer account secure channel with NLTEST
In addition, you can reset the computer’s password in the domain and secure channel using the built-in Nltest tool:
This command will try to repair the secure channel by resetting the password on the local and domain computers. It doesn’t need domain rejoining or rebooting.
Netdom and Reset-ComputerMachinePassword allow you to specify the user’s credentials. But Nltest works in the context of the current user. Accordingly, if you logon to the computer under the local account, and attempt to execute the command, you’ll receive an access denied error. Because of this, the method doesn’t always work.
You can check if the secure channel has been successfully reestablished using the following command:
The following strings confirm that the trust relationship has been repaired:
Trusted DC Connection Status Status = 0 0x0 NERR_Success Trust Verification Status = 0 0x0 NERR_Success
Machine Account (AD Computer Object) password in Active Directory
When you join the computer to the Active Directory domain, the new computer account object is created for your device and a password is set for it (like for AD users). Trust relationship at this level is provided by the fact that the domain joining is being performed by a Domain administrator account. Or another user with delegated administrative permissions performed the join.
Each time the domain computer logs in to the AD domain, it establishes a secure channel with the nearest domain controller (%logonserver% environment variable). DC checks the computer credentials. In that case, trust is established between the workstation and domain. Further interaction occurs according to administrator-defined security policies.
The computer account password is valid for 30 days (by default) and then changes. You must keep in mind that the computer changes the password according to the configured domain Group Policy. This is like a changing user’s password process.
Tip. You can configure the maximum account password age for domain computers using the GPO parameter Domain member: Maximum machine account password age. It is located in the following Group Policy editor section: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. You can specify the number of days between 0 and 999 (by default it is 30 days).
You can configure a single computer’s machine account password policy through the registry.
To do this, run regedit.exe and go to the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key. Edit the parameter MaximumPasswordAge and set the maximum validity time of the computer password in the domain (in days).
Another option is to completely disable the computer account password change. Do this by setting the REG_DWORD parameter DisablePasswordChange to 1. Although this solution is not recommended for production environments and is only valid for test stands.
You can also change the computer password change settings for a domain using Group Policy. The settings for changing computer account passwords are located under the section: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. We are interested in the following parameters:
- Domain member: Disable machine account password changes — disables the request to change the password on the local computer;
- Domain member: Maximum machine account password age — defines the maximum age for a computer password. This parameter determines the frequency with which a domain member will try to change the password. By default, the period is 30 days; the maximum can be set to 999 days;
- Domain controller: Refuse machine account password changes — disallows password changes on domain controllers. If you enable this option, then the controllers will reject requests from computers to change the password.
The Active Directory domain stores the current computer password and the previous one. If the password was changed twice, the computer that uses the old password won’t be able to authenticate on the domain controller. It won’t establish a secure connection channel.
The computer account passwords don’t expire in Active Directory. This is happening because the Domain Password Policy doesn’t apply to the AD Computer objects. Your computer can use the NETLOGON service to change the password during the next domain logon. This is possible if its password is older than 30 days. Note that the local computer password is not managed by AD, but by the computer itself.
The computer tries to change its password on the domain controller. Only after a successful change, it updates its local password. A local copy of the password is stored in the registry key HKLM\SECURITY\Policy\Secrets$machine.ACC).
You can view the last password set time for a computer object account in the AD domain using the PowerShell cmdlet Get-ADComputer. You can do this from the PowerShell Active Directory Module. Run the command with the computer name:
get-adcomputer -Identity Lon-Com212 -Properties PasswordLastSet
Therefore, even if you did not power on your computer for a few months, the trust relationship between the computer and domain still be remaining. In this case, the computer password will be changed at the first registration of your workstation in the domain.
The trust relationship is broken when a computer tries to authenticate to a domain with an invalid password.
Windows events related to broken Trust Relationship
You can track failed trust relationship events on computers and domain servers by the following IDs in the Event Viewer:
Log Name: System
This computer was not able to set up a secure session with a domain controller in domain “” due to the following:
There are currently no logon servers available to service the logon request. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.
Log Name: System
This computer could not authenticate with \\ny-dc01 a Windows domain controller for domain THEITBROS, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.
Fixing: The security database on the server does not have a computer account for this workstation trust relationship
When the error “The security database on the server does not have a computer account for this workstation trust relationship” appears, you need to check the domain controller error logs for the Event ID 2974:
The attribute value provided is not unique in the forest or partition. Attribute: servicePrincipalName Value=TERMSRV/PDC
CN=PC1,OU=Computers,DC=theitbros,DC=com Winerror: 8647
This issue indicates that the SPN (Service Principal Name) computer account attribute in AD is not properly populated. Also, check if several computers are in the domain with the same value in the servicePrincipalName attribute.
Find the problematic computer object in the ADUC console. Go to the Attribute Editor tab, and check the value of the servicePrincipalName attribute.
Make sure your computer object has a populated SPN property value in the following format:
You can copy the computer FQDN (Fully Qualified Domain Name) from the dNSHostName attribute. If these SPN records are missing, you must create them manually.
Now restart your computer and try to logon under domain credentials.
Duplicated SPNs in the domain can be found using the ldifde utility:
ldifde -f C:\ps\SPNList.txt -t 3268 -d DC=theitbros,DC=com -l serviceprincipalname -r (serviceprincipalname=*)
Fix Trust Relationship FAQs
1. What does a Trust Relationship Failed error look like, and when can it occur?
A Trust Relationship Failed error typically appears when a user tries to log in to a workstation or server with domain account credentials. The error message may look like this:
- The trust relationship between this workstation and the primary domain failed
- The security database on the server does not have a computer account for this workstation trust relationship
This error indicates that the computer is no longer trusted, as the local computer’s password does not match the computer’s object password stored in the AD database.
2. What are the common causes of Trust Relationship Failed errors?
Trust Relationship Failed errors can occur due to:
- Reinstalling Windows
- Restoring the computer system state from an image backup or Virtual machine snapshot
- Cloning a computer without running Sysprep
- Manually resetting the computer’s domain account
- Removing the computer account object from Active Directory Domain Services (AD DS)
- Adding a computer with the same hostname to the domain accidentally
- Local time on the computer being offset by more than 5 minutes from the authenticating domain controller
- Domain controllers experiencing replication problems
3. How can I fix a Trust Relationship Failed error?
To fix this error, you can:
- Check the secure channel between the workstation and the primary domain using Test-ComputerSecureChannel cmdlet in PowerShell
- Ensure the computer account is present and not disabled in Active Directory
- Repair the failed trust relationship without rejoining the domain using PowerShell cmdlets like Reset-ComputerMachinePassword
- Fix the trust relationship by rejoining the domain, which involves resetting the local admin password, unjoining and rejoining the computer to the domain, and rebooting
4. Are there any alternatives to PowerShell for fixing Trust Relationship Failed errors?
Yes, you can use the Netdom utility, available in Windows Server since the 2008 version and as part of the RSAT (Remote Server Administration Tools) package for clients. To fix the error with Netdom, log in to the target system with the local Administrator account, open the elevated command prompt, and run the following command:
Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password
5. What should I do if the time difference between my computer and the domain controller is more than 5 minutes?
If the time difference between your computer and the domain controller is more than 5 minutes, you need to sync your computer’s time with the domain controller. You can check your Window Time service source using the command w32tm.exe /query /source and follow a guide to check and sync time with the domain controller. Ensuring correct time synchronization is important for establishing a trust relationship with the domain controller.
As you can see, it’s quite easy to solve the Trust relationship failed issue in a domain using a methodical and step-by-step troubleshooting approach! The issue can occur due to many reasons. It is important to understand what caused the domain join issue and then use the appropriate steps to resolve it. Hope this was useful for you!
I searching for information WHEN a shutdown computer loose contact with AD and need to be ReJoined.
This article first states that, despite password expired in 30days, the computer will fix that during first startup, even if it´s down for a few months.
Later, the article states that the Trust Relationship will fail due to the computer was turned off for a long time.
So, at a first glance it states: Computers will not expire/loose contact with AD despite shutdown for a long time, at least a few months. But still, if shutdown for a long time they will loose the trust relationship anyhow.
i have the same issue, every time that i restart the PC it loses communication with AD
Test-ComputerSecureChannel -Repair -Credential corp\dsmith
i have serious issues !
i have LAPS on my Domain,
1. trust relationship failed ! —-> so no domain logon possible
2. LAPS not helping when we dont have trust relationship ( + local admin removal policy enabled) —->so no local logon possible
what sould i do?!!
Unplug the computer from the network. You can then logon using cached credentials on the PC provided you have logged on the the PC at least once as a domain admin. Replace the network cable and reset secure channel.
Thank you so much for this information.
Here is how i fixed it (local admin was deactivated)
1. Try login -> doesnt work
2. Remove network connection (unplug ethernet)
3. Login with domain credentials
4. PS: Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin
6. Plug-in Ethernet
7. Try login -> works
you are awesome alex. thank you.
i fixed my issue.
i am wondering i can trust this computer from AD
which command can fix this from AD without login in client pc,
This resolved my issue by using the PowerShell option. Thanks for explaining everything! You saved my bacon!
So I have had this happen to my entire system. Every server I had has lost the trust relationship. What would cause this to happen? This has caused some serious outages and disruptions. I still have a couple of servers that lose the Trust relationship randomly.
Is it possible that a user account could be the problem? The reason I ask is because I use a very specific UN: and PW: for the services running on every server.
Thank you so much for this, saved my grade big time
Thanks for this! I was troubleshooting a problem and just didn’t think to check if the AD account had been disabled.
Absolutely a GREAT article. Explains everything so well and I was able to fix my broken trust with just a few commands! Now I know why the trust gets broken and I can avoid the issue all together!
Many many thanks. amazing article! I learned a lot from this one.
this command worked perfectly for me
windows server 2016
Many many thanks!
Thanks for the article. I have not had this problem in years but when it just happened I was not wanting the manual re-join since it messes up local profiles.
I was able to use PS and CLI and it is a much better solution!
Did you find any solution for that? i am facing the same at production env.
I am facing the same problem of hesam .
LAPS changed the admin password, but with the trust relationship lost, the password doesn’t work…
Windows had an error and returned to a restore point prior to changing the password, both for the computer and for the administrator.
so it lost trust and i can’t log on locally.
How can I restore the trust relationship if I can’t log into the computer?
An admin before us modified the c:\windows\system32\drivers\etc\hosts with new lines for the file server and DC’s. This was ultimately the cause for our Trust relationship issues. We removed these lines, reboot, and all was well again.
i don t have netlogon event 5719 on my events logs, how can i get it , because i want to apply scheduled task when it appear
Comments are closed.