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 user is trying to login to workstation or server with domain account credential 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 may be like this:
The security database on the server does not have a computer account for this workstation trust relationship
What is the cause for “The trust relationship between this workstation and the primary domain failed” error?
Let’s try to understand what does this error means and how to fix it.
When you join the computer to Active Directory domain, the new ccomputer 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 operation is performed by Domain administrator or another user with the appropriate permissions.
Each time when domain computer login to the AD domain, it establish a secure channel with a closest domain controller and send the 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. It is important to understand that the change of password initiated by computer is defined by Domain group policies. This is similar to the changing user password process.
Tip. You can configure maximum account password age for domain computers using the GPO policy Domain member: Maximum machine account password age, which is located in the following GPO editor section: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. You can specify number of days between 0 and 999 (by default it is 30 days).
For a single machine, you can configure the 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 value of the MaximumPasswordAge parameter, in which you can specify the maximum period of validity of the computer password in the domain (in days). Other option is to completely disable sending a request for computer password updates, by changing the value of the DisablePasswordChange parameter 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 old password will not be able to authenticate on the domain controller and establish a secure connection.
Computer account passwords do not expire in Active Directory, because domain password policies doesn’t apply to the AD Computer objects. Your computer using the Netlogon service can change the password automatically during 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). First, 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).
Therefore, even if you did not power on your computer for a few months, trust relationship between computer and domain still be remaining and the password will be changed at first registration of your workstation in the domain.
Trust relationship failed if computer tries to authenticate on domain with an invalid password. Typically, this occurs after reinstalling the OS, then the system state was restore from an image (backup) or snapshot of the Virtual machine, or it was just turned off for a long time, 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 domain will be different.
First of all, open the Active Directory Users and Computers (ADUC) snap-in and make sure that the account of the problematic computer is present in the domain and is not locked.
The most obvious old-school way to restore trust relationship of your computer in the domain is:
- Reset local Admin password;
- Switch 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 is not reconnecting correctly after computer domain rejoining (https://theitbros.com/user-profile-service-failed-the-sign-in/).
We will show how to restore a trust relationship and restore 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.
Using Netdom resetpwd to Fix Trust Relationship Failed
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) and run following command:
Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password
- Server – name of any domain controller
- UserD – username with domain admin 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 login under domain credentials.
You can check a secure connection to the AD domain using Netdom by using 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 name from the computer to which the trust is lost.
Reset-ComputerMachinePassword using PowerShell
You can reset computer password with the help of PowerShell cmdlet Reset-ComputerMachinePassword. This is the fastest and most convenient way to reset the password of a computer and doesn’t require computer reboot. Unlike the Netdom utility, PowerShell 3.0 is already included in 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 as a local Administrator, run the elevated PowerShell console as and execute this command:
Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin
- Server – name of any domain controller
- Credential – user with domain admin permissions
Reset-ComputerMachinePassword -Server lon-dc01 -Credential corp\dsmith
The credentials window will appear and you must type the password you specified for Domain administrator account.
Cmdlet doesn’t display any messages on success, so just change your logon account, no reboot required.
Tip. Same operation can be performed using PowerShell cmdlet Test-ComputerSecureChannel:
Test-ComputerSecureChannel -Repair -Credential corp\dsmith
You can check that secured channel has been successfully reestablished using following command:
The following strings confirm that trust relationship has been repaired:
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
In addition, you can reset the computer’s password in the domain and use the Nltest utility:
However, unlike Netdom and Reset-ComputerMachinePassword, which provides input of user credentials, Nltest works in the context of the user who launched it. 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.
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 logs for an error with 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 problem is related to the fact that the computer account in AD is not filled with the SPN (Service Principal Name) attribute or there are several computers in the domain with the same data in the servicePrincipalName attribute.
Find the problem computer in the ADUC console, go to the Attribute Editor tab and check the value of the servicePrincipalName attribute
Make sure your computer object has the filled SPN record in the following format:
The FQDN of the computer name must be copied from the dNSHostName attribute. If these SPN records are missing, you must create them manually.
After that 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!