In this article, we will discuss the causes of Trust relationship failed error and some solutions on how to restore secure channel between the workstation and the Active Directory domain.
In what case we can get this error? For example, when a user is trying to login to workstation or server with domain account credentials and after entering the username and its 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
Let’s try to understand what does this error means and how to fix it.
Active Directory Machine Account Password
When you join the computer to 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 join is performed by a Domain administrator or another user with delegated administrative permissions.
Each time when domain computer login to the AD domain, it establishes a secure channel with the nearest domain controller and sends the computer credentials. In that case, trust is established between the workstation and domain and further interaction occurs according to administrator-defined security policies.
The computer account password is valid for 30 days (by default) and then automatically changes. You must keep in mind that the password is changed by the computer according with the configured domain Group Policy. This is similar to the changing user 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, which 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 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 by set the REG_DWORD parameter DisablePasswordChange to 1.
The Active Directory domain stores the current computer password, as well as the previous one. If the password was changed twice, the computer that is using an old password will not be able to authenticate on the domain controller and establish a secure connection channel.
The computer account passwords do not expire in Active Directory, because the Domain Password Policy don’t apply to the AD Computer objects. Your computer can use the NETLOGON service to change the password automatically during the next domain logon if its password is older than 30 days (note that the local computer password is not controlled by AD, but by the computer itself).
The computer tries to change its password on the domain controller, and 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 last password set time for a computer object account in the AD domain using the PowerShell cmdlet Get-ADComputer (from the AD for Windows PowerShell 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 computer and domain still be remaining and the computer password will be changed at first registration of your workstation in the domain.
What is the Cause for “The Trust Relationship between this Workstation and the Primary Domain Failed” Error?
This error indicates that this computer in no longer trusted and diconnected from the Active Directory since the local computer password doesn’t match this computer object password stored in the AD database.
Trust relationship may fail if the computer tries to authenticate on a domain with an invalid password. Typically, this occurs after reinstalling Windows, then the system state was restored from an image (backup), Virtual machine snapshot, or when performing computer cloning without running 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 that the computer local password is in sync with computer account password on the domain controlled with 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”.
VERBOSE: The secure channel between the local computer and the domain theitbros.com is in good condition.
Fixing Trust Relationship by Domain Rejoin
First of all, open the Active Directory Users and Computers (ADUC) snap-in and make sure that the problem computer account is present in the domain and is not disabled.
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;
- 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 way and requires multiple reboots. Also, we know cases when the local user profiles are not reconnecting correctly after computer domain rejoining.
We will show how to reestablish a trust relationship and restore a secure channel without domain rejoin and reboot!
Tip. It is extremely important to make sure that the time difference between the domain controller and the client computer’s less than 5 minutes. To properly configure time synchronization in a domain, see the article Configuring NTP on Windows using GPO.
Reset-ComputerMachinePassword: How to Fix Failed Trust Relationship with PowerShell?
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 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, run the elevated PowerShell console and execute this command:
Reset-ComputerMachinePassword -Server DomainController -Credential DomainAdmin
- Server – the name of any domain controller;
- Credential – a domain user (with permission to add the computer to the domain) or domain admin account.
Reset-ComputerMachinePassword -Server lon-dc01 -Credential corpdsmith
The credentials window will appear and you must type the domain account password.
Cmdlet doesn’t display any messages on success, so just re-login under domain account, no reboot required.
If your received the error message “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.
Tip. You can also repair secure channel between computer and Active Directory domain using PowerShell cmdlet Test-ComputerSecureChannel:
Test-ComputerSecureChannel -Repair -Credential corpdsmith
Using Netdom resetpwd to Fix Trust Relationship Failed without Reboot
You can find Netdom utility in Windows Server since 2008 version. It can be installed on client PC as 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 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 successful execution of this command, 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, because it is not always possible to authorize on the domain controller under the administrator account from a computer this broken-trust relationship.
Reset Active Directory Secure Channel and Computer Password Using 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 both on the local computer and on the domain computer, and it doesn’t require domain rejoining or rebooting.
However, unlike Netdom and Reset-ComputerMachinePassword, which allow you to specify user credentials, Nltest works in the context of the current user. Accordingly, if you logon to the computer under the local account and attempting to execute the command, you will receive an access denied error. Because of this, the method doesn’t always work.
You can check that 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
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 or there are several computers in the domain with the same value in the servicePrincipalName attribute.
Find the problem 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.
Duplicate 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 is quite easy to solve Trust relationship failed issue in a domain! Hope this was useful for you!
- How to Migrate DHCP Server to Windows Server 2016/2019? - August 7, 2020
- How to Find Active Directory Nested Group Members? - August 1, 2020
- Sysprep a Windows 7 Machine – Start to Finish V2 - July 31, 2020