Fix Trust relationship Failed Issue Without Domain Rejoining

2.2K

In this article, we’ll discuss the causes of the Failed Trust Relationship error and the ways to fix the issue. This guide covers possible solutions to restore a secure channel and trust relationship between the workstation and the Active Directory domain.

You may encounter this error when a user tries to log in to a domain-joined workstation or server using domain account credentials. After entering valid domain user credentials, the following error message is displayed:

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 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 restoring the computer from an image backup (SystemState) or a virtual machine snapshot;
• If you used Windows Reset;
• If you have cloned the Windows image without first running Sysprep;
• Someone has manually reset this computer’s domain account in Active Directory;
• Your computer account object has been removed from the AD;
• Someone accidentally adds a computer with the same hostname to the domain;
• Your domain controllers are experiencing replication issues — the new computer account password has not been synchronized with the domain controller you use for authentication (Logon server). Check the AD replication with repadmin tool.

In all of these cases, your computer can’t establish a trusted (secure) connection to a domain controller as the local computer’s password does not match the computer’s object password stored in the AD database.

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?

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.

To fix this error, you need to:

• 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

Check Secure Channel Between Workstation and the Primary Domain

You can check if 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, start the PowerShell console, and run the Test-ComputerSecureChannel cmdlet.

Test-ComputerSecureChannel

Note. If the Test-ComputerSecureChannel command returns a “Network Path Not Found” error, check your network connectivity.

Or you can add –Verbose switch parameter:

Test-ComputerSecureChannel -Verbose

Hint. If you are unable to log to your computer using an Active Directory user account, try temporarily disconnecting the network cable. In this case, you can log on to the computer using the cached credentials of the AD user. Reconnect the network cable after you have logged on to Windows.

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.

Check your hostname with the command:

$env:computername

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.

If the computer account doesn’t exist, create it on the domain controller using the ADUC snap-in or using PowerShell:

New-ADComputer -Name "YourHostName" -SamAccountName "YourHostName" -Path "OU=Computer,OU=London,OU=UK,DC=THEITBROS,DC=COM"

Repair Trust Relationship with PowerShell

You can reset the computer password by using the PowerShell cmdlet Reset-ComputerMachinePassword.

The Reset-ComputerMachinePassword cmdlet resets the password which is used by the local computer to authenticate to domain controller AD and synchronize it with AD.

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.

Open an elevated PowerShell prompt and run the command:

Reset-ComputerMachinePassword -Server lon-dc01 -Credential corp\dsmith

• Server — is the FQDN name of the nearest domain controller;
• Credential — domain user (with permission to join the computer to the domain) or domain admin account.

You will need to enter the password for the domain account in the credentials prompt.

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

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

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.

Check and Repair Secure Channel with Netdom

You can also use the netdom.exe tool from RSAT to reset the local computer password. Sign in failed machine 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 domain name;
• UserD — username with domain admin or delegated privileges;

Netdom resetpwd /Server:corp.contoso.com /UserD:dsmith /PasswordD:*

Once this command has been successfully executed, no reboot is required. Just logout from a local account, and log in using domain credentials.

You can check a computer secure channel with an AD domain with the command:

Netdom Verify WK_Salary12 /Domain:corp.contoso.com /UserO:dsmith /PasswordO:*

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 (use the System Properties dialog box — sysdm.cpl);
   
3. Reboot;
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 the easiest, but not the fastest or most convenient, and it requires multiple restarts. 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.

You can also use PowerShell to remove and join your computer to an AD domain. Use the following built-in PowerShell cmdlets: Remove-Computer and Add-Computer.

The following command will unjoin your device from the domain and force the host to reboot:

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

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 password is set for it (like for AD users). The fact that the domain joining is done by a domain admin provides the trust relationship at this level.

The domain computer establishes a secure channel with the nearest domain controller each time it logs on to the AD domain (%logonserver% environment variable). DC checks the computer credentials. In that case, trust is established between the workstation and the domain.

The computer account password is valid for 30 days (by default) and then changes automatically. You must keep in mind that the computer changes the password according to the configured domain Group Policy. This is similar to the process of changing a user’s password.

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.

• Domain member: Disable machine account password changes — disables local computer password changes (is not recommended for production environments and is for testing only);
• 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; This policy sets the MaximumPasswordAge registry parameter on the computers at HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameter;
• Domain controller: Refuse machine account password changes — disables password changes on domain controllers. If you enable this option, then the DC will reject requests from computers to change the password.

The Active Directory stores the current computer password and the previous one. If the password has been 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. Your computer uses the NETLOGON service to change the password during the domain logon. This is possible even 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 use the Get-ADComputer PowerShell cmdlet to find out the time that the password was last set for a computer object account in the AD domain. To do this, use the PowerShell Active Directory module. Type your hostname in the command:

get-adcomputer -Identity Lon-Com212 -Properties PasswordLastSet

This means that even if you have not turned on your computer for a couple of months, the trust relationship between the computer and the domain is still in place. In this case, the computer password will be changed at the first registration of your workstation in the domain.

However, the trust relationship is broken if you restore your computer from a snapshot after the computer’s password has been automatically changed in AD several times.