Windows OS Hub
  • Windows
    • Windows 11
    • Windows Server 2022
    • Windows 10
    • Windows Server 2019
    • Windows Server 2016
  • Microsoft
    • Active Directory (AD DS)
    • Group Policies (GPOs)
    • Exchange Server
    • Azure and Microsoft 365
    • Microsoft Office
  • Virtualization
    • VMware
    • Hyper-V
  • PowerShell
  • Linux
  • Home
  • About

Windows OS Hub

  • Windows
    • Windows 11
    • Windows Server 2022
    • Windows 10
    • Windows Server 2019
    • Windows Server 2016
  • Microsoft
    • Active Directory (AD DS)
    • Group Policies (GPOs)
    • Exchange Server
    • Azure and Microsoft 365
    • Microsoft Office
  • Virtualization
    • VMware
    • Hyper-V
  • PowerShell
  • Linux

 Windows OS Hub / Active Directory / Repairing the Domain Trust Relationship Between Workstation and Active Directory

May 16, 2024 Active DirectoryPowerShellWindows 10Windows 11Windows Server 2019

Repairing the Domain Trust Relationship Between Workstation and Active Directory

If a trust relationship between a Windows workstation and an Active Directory domain is broken, the computer won’t be able to establish a secure channel with the domain controller, and domain users will not be able to authenticate to that computer. In this article, we will look at the root causes of why Windows machines can fall off the AD domain and a simple way to restore a trust relationship between a computer and a domain without reboot.

Contents:
  • The Trust Relationship Between This Workstation and the Primary Domain Failed
  • Repair Broken Trust Between Computer and Domain with PowerShell
  • Machine (Computer) Account Password in Active Directory

The Trust Relationship Between This Workstation and the Primary Domain Failed

If a computer is not in a trust relationship with a domain, you will get an error when you try to log on to that computer as a domain user:

The trust relationship between this workstation and the primary domain failed.

windows 10 domain user logon error: The trust relationship between this workstation and the primary domain failed.

The error may also look like this:

The security database on the server does not have a computer account for this workstation trust relationship.

The security database on the server does not have a computer account for this workstation trust relationship.

Repair Broken Trust Between Computer and Domain with PowerShell

Typically, administrators in this situation simply remove the computer from the domain and rejoin it to AD. This method works well but requires a lot of time and several computer restarts. It’s much faster and easier to restore the trust relationship between the workstation and the domain using PowerShell (without rejoining the domain or restarting the computer).

To restore trust between the machine and the domain, you need to log on to the computer locally using any account with local administrator privileges. This can be a local user with administrator permissions, or the built-in Windows administrator (if you don’t know your local administrator password, you can reset it).

By default, Windows caches the credentials of the last ten domain users who have logged on to the computer locally. Therefore, if you unplug the network cable while logging on to the computer, you will be able to sign in using the cached domain user credentials.

To log on to the computer as a local user, enter the local user name on the sign-in screen in the format: .\localuser . The dot at the beginning of the name indicates that the local account database should be used.

logging into a local windows user account

Open an elevated PowerShell console and check to see if the computer is in a trust relationship with the AD domain:

Test-ComputerSecureChannel –Verbose

Test-ComputerSecureChannel -The Secure channel between the local computer and the domain is broken

The computer cannot establish trust with the domain if the computer’s local password and the domain password do not match and the command will return:

False – The Secure channel between the local computer and the domain woshub.com is broken.

To force restore the trust relationship between the current workstation and the domain, run the following command:

Test-ComputerSecureChannel -Repair -Credential woshub\administrator -Verbose

Test-ComputerSecureChannel repair domain trust

Specify the credentials of the domain administrator or a user who has been delegated the permissions to manage computers in the AD.

If the computer can connect to the DC and set a new password for its account, thereby restoring trust with AD, a message will be displayed:

True. The secure channel between the local computer and the domain woshub.loc was successfully repaired.

Check that trust has been successfully restored. Run Test-ComputerSecureChannel again to make sure it returns:

 True. The Secure channel between the local computer and the domain woshub.com is in good condition.

Log off the local user and sign in to the computer as a domain user (no reboot required).

However, to update the domain Group Policy settings on the computer, it must be restarted.

You can also use this command to force reset and sync your computer’s password.:

Reset-ComputerMachinePassword -Server mun-dc01.woshub.com -Credential woshub\administrator

mun-dc01.woshub.com – is the name of the closest DC.

In some cases, the trust repair command may return an error:

The attempt to repair the secure channel between the local computer and the domain woshub.loc has failed.

In this case, you need to check that the domain can be connected from the computer, that this computer account exists in the domain, that it is not disabled, and that you have the permissions to manage it. To find out the name of your computer, use the hostname command. Open the Active Directory Users and Computers snap-in (dsa.msc) and find the account for this computer. In this example, it is disabled. Re-enable it.

enable AD computer account

Machine (Computer) Account Password in Active Directory

Why is it possible for the trust relationship between a computer and a domain to fail?

When a computer is joined to an Active Directory domain, a separate computer account is created for it. Each computer in the domain has its own password, which is used to authenticate to the domain and establish a trusted connection with the domain controller. By default, this password changes automatically every 30 days and is stored locally on the computer (under the registry key HKLM\SECURITY\Policy\Secrets\$machine.ACC) and in the AD. The frequency of computer password changes is set by the Domain member: Maximum machine account password age GPO option.

Unlike user passwords, the computer password doesn’t expire. The computer, not the domain controller, initiates the password change.

Even if the computer has been powered off for more than 30 days, you can turn it on and it will authenticate to the DC normally using the old password. The local Netlogon service then changes the computer’s password in its local database and updates it in Active Directory.

If the hash of the password that the computer sends to the domain controller doesn’t match the computer’s account password in the AD, it won’t be able to establish a secure connection to the DC and will return a trust relationship error.

The most common reasons that cause the failed trust relationship error:

  1. A computer has been restored from an old restore point or a snapshot (if it is a virtual machine) that was created before the computer’s password was changed in AD. This means that the machine password in the snapshot differs from the AD computer object password. Before taking a snapshot, it is recommended that you force a computer in the domain to change its password using the command: nltest.exe /sc_change_pwd:woshub.loc
  2. The computer has been cloned without using the Sysprep tool;
  3. A new computer object with the same name has been created in AD, or someone has reset the computer account in the domain using the ADUC console (dsa.msc); reset computer account in active directory using ADUC
  4. The computer account in the domain has been disabled by the administrator (for example, during a regular procedure of disabling inactive AD objects);
  5. If the local system time on your computer is incorrect or Windows time synchronization has failed.

For test VMs that need to be frequently restored from snapshots or restore points, you can use the GPO parameter to disable regular password changes (Domain member: Disable machine account password changes in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options).

11 comments
11
Facebook Twitter Google + Pinterest
previous post
Enabling DNS over HTTPS (DoH) on Windows 11
next post
How to Enable Windows Auto Login without a Password

Related Reading

Configure NTP Time Source for Active Directory Domain

May 6, 2025

How to Cancel Windows Update Pending Restart Loop

May 6, 2025

View Windows Update History with PowerShell (CMD)

April 30, 2025

Change BIOS from Legacy to UEFI without Reinstalling...

April 21, 2025

Remove ‘Your License isn’t Genuine’ Banner in MS...

April 21, 2025

11 comments

Shlomi March 13, 2021 - 6:56 pm

Amazing!!
Many thanks

Reply
Austin February 2, 2023 - 10:35 pm

Question: If I cannot login the computer (virtual machine), how to ?
I also have local admin credential, but when I try to login, it always say wrong username or password.

Reply
Austin February 2, 2023 - 10:39 pm

Question: If I cannot login the computer (virtual machine), how to do “Open the elevated PowerShell console and using Test-ComputerSecureChannel cmdlet make sure if the local computer password matches the password stored in AD.” ?
I also have local admin credential, but when I try to login, it always say wrong username or password.

Reply
admin February 10, 2023 - 10:22 am

If you are logged into the computer local user, check the workstation interrelationship with the command:
Test-ComputerSecureChannel -Server DCName

Reply
Ali April 25, 2023 - 8:55 am

When signing in using administraitor is says trust is broken
When signing in using local administrator is says disalbled check with your administrator

Reply
Karl November 23, 2024 - 3:38 pm

Have situation where all domain computers and servers have a broken relation to the domain. Also “ping” results in general failure.
Attempting to repair as advised here fails.
This was a result of my amateur attempt to heighten security by imposing strict group policies and firewall rules. Unfortunately, I have not been able to reestablish no matter how I go back. Have followed all available instructions regarding DNS, firewall etc but after several days still to no avail. Any suggestions?

Reply
Karl November 24, 2024 - 1:21 pm

For some reason it helped to switch network on servers from fixed IP address to DHCP, restart and then go back to fixed IP. On PCs it was enough to switch from WiFi to network cable or vice versa. Apparently the network settings needed to be freshened up, and all the standard attempts to do so had not worked. Anyways, back on track 🙂

Reply
admin November 26, 2024 - 6:04 am

It looks like your network connection profile on clients has been reset to Private. Your actions help switch it back to domainprofile.

Reply
admin November 26, 2024 - 6:00 am

You probably need to start by undoing the changes you made. If all changes are made through the domain GPO, simply unlink them from the OUs.

Reply
Karl November 26, 2024 - 10:30 am

Thanks for your replies. I got all but one computers back on track. The last one is running Windows 11. As nothing else worked I tried to delete it in Active Directory and DNS hoping that I would be able to rejoin the computer to the domain. That is not the case. The computer seems to be locked in the belief that it is a domain member although it will not connect to the domain. I cannot rename the computer either. Can work on the computer using a local account, but obviously no access to network folders etc. Wonder how I can get this one back into the domain?

Reply
admin December 3, 2024 - 7:22 am

Try resetting any changes made to the device by the domain GPO.
Clear Domain-Applied Group Policy Settings in Windows

Reply

Leave a Comment Cancel Reply

join us telegram channel https://t.me/woshub
Join WindowsHub Telegram channel to get the latest updates!

Categories

  • Active Directory
  • Group Policies
  • Exchange Server
  • Microsoft 365
  • Azure
  • Windows 11
  • Windows 10
  • Windows Server 2022
  • Windows Server 2019
  • Windows Server 2016
  • PowerShell
  • VMware
  • Hyper-V
  • Linux
  • MS Office

Recent Posts

  • Cannot Install Network Adapter Drivers on Windows Server

    April 29, 2025
  • Change BIOS from Legacy to UEFI without Reinstalling Windows

    April 21, 2025
  • How to Prefer IPv4 over IPv6 in Windows Networks

    April 9, 2025
  • Load Drivers from WinPE or Recovery CMD

    March 26, 2025
  • How to Block Common (Weak) Passwords in Active Directory

    March 25, 2025
  • Fix: The referenced assembly could not be found error (0x80073701) on Windows

    March 17, 2025
  • Exclude a Specific User or Computer from Group Policy

    March 12, 2025
  • AD Domain Join: Computer Account Re-use Blocked

    March 11, 2025
  • How to Write Logs to the Windows Event Viewer from PowerShell/CMD

    March 3, 2025
  • How to Hide (Block) a Specific Windows Update

    February 25, 2025

Follow us

  • Facebook
  • Twitter
  • Telegram
Popular Posts
  • Configure Google Chrome Settings with Group Policy
  • Get-ADUser: Find Active Directory User Info with PowerShell
  • How to Find the Source of Account Lockouts in Active Directory
  • How to Disable or Enable USB Drives in Windows using Group Policy
  • Get-ADComputer: Find Computer Properties in Active Directory with PowerShell
  • Configuring Proxy Settings on Windows Using Group Policy Preferences
  • Adding Domain Users to the Local Administrators Group in Windows
Footer Logo

@2014 - 2024 - Windows OS Hub. All about operating systems for sysadmins


Back To Top