In this article, we’ll discuss the causes for the Trust relationship failed error. This guide covers possible solutions on how to restore a secure channel between the workstation and the Active Directory domain. Show
In what case you can face this error? For example, when a user is trying to login to a workstation or server with domain account credentials. After entering the username and password, a window appears (with an error message):
Or the error looks like this:
At the same time, events with EventID 5719 with the source NETLOGON appear in the System section of the Event Viewer:
Also in the System section of the Event Viewer, you can find the error with Event ID 3210 from the NETLOGON source:
Let’s try to understand what does this error means and how to fix it. Active Directory Machine Account PasswordWhen you join the computer to the Active Directory domain, the new computer account 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. 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.
You can configure the machine account password policy for a single computer 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:
The Active Directory domain stores the current computer password, as well as 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 AD Windows PowerShell module. Run the command with the computer name: get-adcomputer -Identity Lon-Com212 -Properties PasswordLastSetTherefore, even if you did not power on your computer for a few months, the trust relationship between 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. What is the Cause for “The Trust Relationship between this Workstation and the Primary Domain Failed” Error?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. A trust relationship may fail if the computer tries to authenticate on a domain with an invalid password. Typically, this occurs after reinstalling Windows. Also, when the system state was restored from an image backup (or SystemState), Virtual machine snapshot, or when performing computer cloning without running the Sysprep. 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 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, logon computer under the local administrator (!!!) account, start the PowerShell console, and run the Test-ComputerSecureChannel cmdlet. You can use a simple form: Test-ComputerSecureChannelOr you can add –Verbose switch parameter: Test-ComputerSecureChannel -VerboseVERBOSE: 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.
Fixing Trust Relationship by Domain RejoinFirst of all, 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. The most obvious old-school way to restore the trust relationship of your computer in the domain is:
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. 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
We will show how to reestablish a trust relationship, and restore a secure channel without domain rejoin and reboot! 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 –RestartThis 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 -RestartIt is important to make sure the time difference between the domain controller and the client computer is less than 5 minutes. To configure time synchronization in a domain, read the article Configuring NTP on Windows using GPO. 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:
Check your Window Time service source using the command: w32tm.exe /query /sourceIf 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 synchronize with DC. Reset-ComputerMachinePassword: How to Fix Failed Trust Relationship with PowerShell?Check if your computer account has not been removed from Active Directory: #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"You can reset the computer password using the PowerShell cmdlet Reset-ComputerMachinePassword.
This is the fastest and most convenient way to reset the password of a computer and doesn’t require a reboot. Unlike the Netdom utility, PowerShell 3.0 or newer is available on all Microsoft OSs starting with Windows 8/Server 2012. You can install it manually (see here) on Windows 7, Server 2008, and Server 2008 R2 (also requires Net Framework 4.0 or higher).
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
The credentials window will appear, and 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 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 Active Directory domain controller could not be contacted.
Using Netdom resetpwd to Fix Trust Relationship Failed without RebootYou 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 (!!!) credentials (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
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. Reset Active Directory Secure Channel and Computer Password Using NLTESTIn addition, you can reset the computer’s password in the domain and secure channel using the built-in Nltest tool: Nltest /sc_change_pwd:corp.Contoso.comThis command will try to repair the secure channel by resetting the password both on the local computer and on the domain computer. 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: nltest /sc_verify:corp.contoso.comThe following strings confirm that the trust relationship has been repaired: Trusted DC Connection Status Status = 0 0x0 NERR_SuccessTrust Verification Status = 0 0x0 NERR_Success Fixing: The security database on the server does not have a computer account for this workstation trust relationshipWhen 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:
This issue indicates that the SPN (Service Principal Name) computer account attribute in AD is not properly populated. Also, check if there are several computers 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=*)As you can see, it’s quite easy to solve the Trust relationship failed issue in a domain! Hope this was useful for you!
I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion. How do you bypass trust relationship between workstation and primary domain failed?How to Fix The “Trust Relationship Between This Workstation And The Primary Domain Failed” Error. Checking the trust relationship with the Test-ComputerSecureChannel command.. Checking DHCP settings.. Resetting a machine account password. ... . Rejoin your machine to the Active Directory domain.. How do I fix trust relationship and domain failed?Here is the classical way to repair trust relationship between the computer and domain:. Reset the computer account in AD;. Move the computer from the domain to a workgroup under the local administrator;. Reboot;. Rejoin the computer to the domain;. Restart the computer again.. 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 I remove a domain trust relationship?Firstly you have to stop domain x trusting domain y, then remove domain x's ability to trust domain y:. Logon as Administrator to domain x.. Start User Manager for Domains, and click Trust Relationships from the Policies menu.. Select domain y from the Trusted Domains and click Remove and confirm.. |