Fix Trust relationship Failed Issue Without Domain Rejoining

2.6K

In this article, we’ll discuss the causes of the Failed Trust Relationship error and the ways to restore a secure channel and trust relationship between the workstation and the primary Active Directory domain.

When a user tries to log on to a domain-joined computer using the domain account credentials, an error may occur:

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

What is the Cause of a Trust Relationship Failed Error?

A password is set for a computer’s object account when it joins an AD domain. This machine account password is stored in both the Active Directory database and a local registry key. This password is automatically changed every 30 days.

If the local machine account password doesn’t match the computer’s password stored in Active Directory, this means that the computer loses the trust relationship with the domain and can’t establish a trusted (secure) connection. Users will not be able to authenticate to the domain from such a computer.

Typically, this occurs when:

• After restoring the machine from an image backup (SystemState) or a virtual machine snapshot;
• If you used Windows Reset;
• If you have cloned the Windows computer without first running Sysprep;
• The account of the computer in the Active Directory has been manually reset or removed;
• There is the computer object in the domain with the same hostname;
• Check the AD domain replication with repadmin tool. The new computer account password may not have been synchronized with the domain controller (Logon Server) you are using for authentication.

Note. See the last section of this article for more details on the computer object account password in AD.

How to Fix Trust Relationship Issue without Domain Rejoining

In order to get rid of the Trust relationship between primary domain failed error, you need to:

• Check the secure channel between the workstation and the primary domain using the Test-ComputerSecureChannel cmdlet;
• Ensure the computer account exists and not disabled in Active Directory;
• Use the Reset-ComputerMachinePassword cmdlet to repair the secure channel without rejoining the domain.

Check the Secure Channel Between Workstation and the Primary Domain

Check that the computer’s local password is synchronized with the computer’s account password on the domain controller. Sign-in Windows under the local Administrator account (by typing, “.\yourlocaladminuser” in the logon prompt), open the elevated PowerShell console, and run the command:

Test-ComputerSecureChannel -Verbose

In this example, the command returned ‘False’. This means that there is no trust between the workstation and the domain.

VERBOSE: The secure channel between the local computer and the domain contoso.com is broken.

Hint. If you cannot log on to your computer, try temporarily unplugging the network cable. In this case, you can log on to the computer using the cached credentials of the AD user. Once you have logged on to Windows, plug the network cable back in again.

Check your computer name with the command:

hostname

Then open the Active Directory Users and Computers snap-in (ADUC) and search for your computer account object. Make sure that your computer account has not been removed from Active Directory and has not been disabled.

Repair Workstation Trust Relationship without Reboot

You can use the Reset-ComputerMachinePassword PowerShell cmdlet to reset the local computer password and synchronize it with AD.

Open an elevated PowerShell prompt and run the command:

Reset-ComputerMachinePassword -Credential corp\dsmith

Specify a domain user with permission to join the computer to the domain or domain administrator account in the Credential parameter. Enter the password for the domain user at the credentials prompt and click OK.

The cmdlet doesn’t display any messages on success, so just re-login under a domain account. No reboot is required.

Check that the trust relationship between the workstation and the domain has been restored.

Test-ComputerSecureChannel -Verbose

Hint. You can also repair a secure channel between the computer and the Active Directory domain using Test-ComputerSecureChannel cmdlet:

Test-ComputerSecureChannel -Repair -Credential corp\dsmith

You may receive the errors The RPC server is unavailable 0x800706ba or An Active Directory domain controller cannot be contacted when you try to use the Reset-ComputerMachinePassword cmdlet. In this case, check the network connectivity and DNS settings on your computer.

Rejoin the Failed Workstation to the Active Directory Domain

Another classic way to fix the trust relationship is to reset the local admin password, unjoin and rejoin the computer to the domain, and reboot.

1. Reset local Admin password on the computer;
2. Unjoin your computer from Domain to Workgroup. Open the System Properties dialog box (sysdm.cpl), click Change, select that the computer is a member of a Workgroup, type the workgroup name and hit OK;
3. Restart the computer;
4. Reset the computer account in the domain using the ADUC console;
5. Join the computer to the domain under the same hostname;
6. Reboot again.

This method is easy to understand, but not the fastest or most convenient, and it requires multiple restarts. We also know of cases where, after the computer rejoins the domain, the local user profiles do not reconnect correctly and users are faced with the User profile service failed the sign-in error.

You can also use the built-in PowerShell cmdlets to remove and rejoin the computer to an AD domain.

Leave the domain and force the host to reboot:

Remove-Computer -UnjoinDomaincredential THEITBROS\AdminAccount -PassThru -Verbose –Restart

Then sign-in under the local administrator account and join your Windows host to Active Directory:

Add-Computer -DomainName THEITBROS -PassThru –Verbose -Restart

Understanding Machine Account 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 random 120-characters password is generated for it. The computer authenticates to the domain using this password. DC checks the computer’s credentials and if they are valid, a secure session is established between the workstation and the domain.

The computer account password is valid for 30 days (by default) and then changes automatically. The computer changes the machine password in accordance with the configured domain policy.

You can configure the settings for changing the computer account password using Group Policy. Navigate to the following GPO section Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.

• Domain member: Disable machine account password changes — disables local computer password changes (not recommended for production environments);
• Domain member: Maximum machine account password age — defines the maximum age for a computer password. This parameter determines how often the domain workstation changes the account password. The default is 30 days. This policy sets the MaximumPasswordAge registry parameter under HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameter;
• Domain controller: Refuse machine account password changes — disables password changes on domain controllers. If you enable this policy, then the DC will reject requests from computers to change the password.

The current and previous computer passwords are stored in Active Directory. If the password has been changed twice, such a computer won’t be able to authenticate on the domain controller and establish a secure channel.

Computer changes password during domain login using NETLOGON service. This is possible even if its password is older than 30 days.

Only after successful AD password change, computer updates local password. A local copy of the machine account password is stored in the registry key HKLM\SECURITY\Policy\Secrets$machine.ACC.

To find out the last time the password for a computer object in the AD domain was changed, use the PowerShell Active Directory module. Type your hostname in the following command:

Get-ADComputer -Identity Lon-Com212 -Properties PasswordLastSet

Computer account passwords don’t expire in Active Directory and the computer accounts are not affected by the domain password age policy. This means that even if you have not turned on your computer for a few months, the trust relationship between the computer and the domain is in a healthy state. In this case, the computer password will be changed at the first registration of your workstation in the domain.