When managing an Active Directory environment, one of the common issues you might encounter is a broken Domain Trust between a workstation, server and the domain. This can be frustrating, especially when domain users are unable to authenticate to the affected computer. Caused by periods of deactivation I face this issue with my test devices once in a while.

In this article, I will share some of the reasons behind this issue and provide a detailed guide on how to repair the trust relationship using PowerShell, a method that is both efficient and does not require a reboot.

Understanding the Domain Trust Relationship

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 and in the Active Directory.If the hash of the password that the computer sends to the domain controller does not match the computer’s account password in the AD, it won’t be able to establish a secure connection to the DC, resulting in a trust relationship error. Here are some common reasons for this issue:

• Restoring from an Old Snapshot: If a computer is restored from an old restore point or a snapshot that was created before the computer’s password was changed in AD, the machine password in the snapshot will differ from the AD computer object password.
• Cloning Without Sysprep: Cloning a computer without using the Sysprep tool can lead to duplicate computer names and passwords, causing trust issues.
• New Computer Object or Reset Computer Account: Manually creating a new computer object with the same name or resetting the computer account in the domain can also break the trust relationship.

Symptoms of a Broken Domain Trust

When the trust relationship between a workstation and the Active Directory domain is broken, you will encounter errors such as:

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

or

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

These errors indicate that the computer cannot establish a secure channel with the domain controller, and domain users will not be able to authenticate to that computer.

In the Event Log you can see an Event 3210 or 5719 from NETLOGON source on the System Event Viewer.

Fix using Reboots

The classic approach mostly seen to fix these kind of issues is requiring a reboot.

Normally, admins just remove the computer from the domain and add it back to AD. This works well but takes a lot of time and a few 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).

1. Login as local Administrator.
2. Open the Computer Properties.
3. Open Domain or workgroup.
4. Change the Computer domain or workgroup.
5. Make it part of the Workgroup TEMP.
6. Restart the computer.
7. Re-join the Domain.

Smarter Fix using Powershell

To restore trust between the machine and the domain, you must log on to the computer locally using an account with local administrator privileges. This can be a local user with administrator permissions, or the built-in Windows administrator. If you do not 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 / disconnect the virtual network card, you will be able to sign in using the cached domain user credentials.

Open your elevated terminal session and check if you have a valid trust relationship with the AD Domain.

VERBOSE: The secure channel between the local computer and the domain ad.hartiga.de is broken.

To repair the trust relationship between the or server and the Active Directory domain, run the following command:

Test-ComputerSecureChannel -Repair -Credential ad.hartiga.de\ah -Verbose

Where you use Active Directory Domain credentials like in my example “ad.hartiga.de with the rights delegated to update the Active Directory Computer object.

If the workstation or server can connect to the Domain Controlled and you have specified an account with the access rights required, you will get the following message

VERBOSE: The secure channel between the local computer and the domain ad.hartiga.de was successfully repaired.

Now you can log off and login with no reboot required.

To restore full functionality apply the Group Policies from the Active Directory domain by running the following command.

gpupdate /force

In my scenario’s I would also confirm I am running the latest software of my 3rd party solutions, so I would run the winget command on Windows 11 or Windows Server 2022 / 2025. If you need to learn more about Winget, please check here.

winget upgrade --all --include-unknown

Conclusion

You can repair a broken trust between your server or workstation using Powershell without requiring a reboot. It would still be recommend to update the Group Policies and reboot, but this can be done after hours or in a planned maintenance window.