Fix Trust relationship Failed Issue Without Domain Rejoining

10K

This article explains the possible causes of the Failed Trust Relationship error and how to restore a secure channel between the workstation and the Active Directory domain.

Note that repairing the secure channel with PowerShell works in most cases, but not always. In many scenarios, rejoining is required, especially when the computer account is missing, corrupted, or has SID mismatch.

What is the Trust Relationship Error in Active Directory?

A failed trust relationship between the workstation and the domain is a common problem for AD administrators. When this problem occurs, the domain user can’t login to their domain-joined computer and receives an error:

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

What is the Cause of a Failed Trust Relationship Error?

Often the cause is a mismatch between the local machine account password and the password stored in AD (note that other factors can also break the secure channel). This password is generated when a computer object joins an AD domain and automatically changed every 30 days.

Don’t forget to validate machine account password freshness. You can do it with the following command, it will check when computer account password was last changed:

Get-ADComputer -Identity COMPUTERNAME -Properties PasswordLastSet |
Select-Object Name, PasswordLastSet

This machine account password is stored in both the Active Directory database and a local registry key and used to authenticate computer in domain. The computer won’t be able to establish a secure channel with the domain if these passwords don’t match.

How to interpret PasswordLastSet value

In case PasswordLastSet is recent (within expected lifecycle):

• Machine account password is likely in sync
• Trust issue is caused by other factors (DNS, DC, replication, time skew)

In case PasswordLastSet is old/unchanged for a long time:

• Machine may be offline/not communicating with a DC
• Machine account password changes may be disabled by Group Policy. If machine account password changes are disabled, the machine will not periodically update its machine account password in AD. You need to check the effective Group Policy setting Domain member: Disable machine account password changes if PasswordLastSet remains unchanged unexpectedly.
• Secure channel password rotation likely failed
• Possible snapshot restore/cloned VM case
• AD replication problems between DCs

Note that PasswordLastSet is suspicious when:

• It has not changed for multiple password rotation cycles (~60–90 days+)
• It does not align with expected domain join date

Why this matters

This value helps distinguish secure channel corruption (often repairable with Test-ComputerSecureChannel) vs identity/state desynchronization (requires reset or domain rejoin).

How to Fix Trust Relationship Issue without Domain Rejoining

To fix the problem, you need to log in to the problem computer under an account with local administrator permissions.

Log in with local administrator or cached credentials

You can sign-in Windows under the local Administrator account (by typing, “.\yourlocaladminuser” in the logon prompt). In case you cannot log in with a domain account, you should try using cached credentials (if they were previously used on the device). Another option is to log in using a local administrator account.

Open an elevated PowerShell console and check the secure channel between the computer and the Active Directory domain:

Test-ComputerSecureChannel -Verbose

The secure channel between the local computer and the domain is broken.

If the command returns ‘False ‘, it means that you need to fix the trust between the workstation and the domain.

Check Netlogon Events

Before repairing the secure channel, you need to check the System event log for recent Netlogon events. Events such as 5719, 5722, and 5723 can provide additional info about secure channel, computer account, or DC connectivity problems.

In case you are working with in enterprise environments, don’t forget to also check for Netlogon events 5827 and 5828. These events can indicate that a device is using an insecure/incompatible Netlogon secure channel config.

Open Event Viewer → Windows Logs → System and filter the log by the NETLOGON source.

Check your computer name:

hostname

Open the Active Directory Users and Computers snap-in (ADUC) and search for your computer account object.

Make sure that the computer account exists and is enabled in AD. Don’t forget to verify that:

• there are no duplicate computer objects
• object has not been recently recreated
• AD replication is healthy

In the Credential parameter, specify the domain user credentials with permission to join computers to AD or your domain admin account.

Once you have verified that the computer account exists and is healthy in AD, run the following command to repair the secure channel:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

When prompted, enter the credentials of a domain administrator or a user with permission to join computers to the domain.

Before you start repairing the secure channel, you should verify basic connectivity:

• Make sure a machine can resolve the domain name (using nslookup)
• Verify that the DC is reachable (use ping, Test-NetConnection)
• Check that the client is using the correct DNS server (domain DNS)

Below you will find a bunch of useful commands to validate DNS and DC connectivity.

To verify domain DNS resolution, run:

Resolve-DnsName theitbros.com

To verify if a DC is reachable, use the command:

Test-NetConnection dc01.contoso.com -Port 389

In case you need to discover the DC currently used by the client, run:

nltest /dsgetdc:theitbros.com

In order to check AD replication health, use the command:

repadmin /replsummary

If the computer password has been successfully reset and synchronized with the AD, the command will return:

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

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

Test-ComputerSecureChannel -Verbose

VERBOSE: The secure channel between the local computer and the domain theitbros.com is in good condition.

This may resolve the problem in cases where the machine account exists and is consistent across DCs. In more complex scenarios, a domain rejoin is required.

How to Validate Secure Channel (nltest vs PowerShell)

Use nltest to verify the secure channel

To validate the secure channel state, use nltest tool:

nltest /sc_verify:domain.local

Repair Secure Channel Using nltest

You can also attempt to repair the secure channel using nltest tool:

nltest /sc_reset:contoso.com

Here is an alternative:

nltest /sc_change_pwd:contoso.com

Note. The commands mentioned above may fail in case the computer account is missing, disabled, affected by AD replication issues, or has been recreated in AD. In such cases, you may need a domain rejoin.

Repair trust using Test-ComputerSecureChannel PowerShell command

Run the following PowerShell command to repair the secure channel with AD (verify secure channel state first with nltest or Test-ComputerSecureChannel before repairing):

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Important to note that Test-ComputerSecureChannel -Repair command will fail in the following cases (rejoining the domain is required):

• account is missing/disabled in AD
• DC is not reachable
• secure channel is broken due to replication problems
• computer object has been recreated (SID mismatch)

Hybrid Microsoft Entra Join Considerations

If the machine is Microsoft Entra hybrid joined, a healthy on-premises AD secure channel does not necessarily mean that Microsoft Entra device registration and authentication are healthy. In order to check the device’s Microsoft Entra join state and authentication status, you can use the following command:

dsregcmd /status

Check values such as AzureAdJoined, DomainJoined, and the SSO/PRT-related status. If the on-premises secure channel is healthy but Microsoft Entra authentication/device registration is failing, you need to troubleshoot the Microsoft Entra/hybrid-join layer separately rather than rejoining the machine to the on-premises domain.

Alternative Reset-ComputerMachinePassword command

The following command is an alternative method available in Windows PowerShell 5.1:

Reset-ComputerMachinePassword -Credential (Get-Credential)

Command	Purpose
Test-ComputerSecureChannel -Repair	Repairs the Netlogon secure channel
Reset-ComputerMachinePassword	Forces a machine account password reset in Active Directory

Checking Netlogon Events for Legacy Devices

In case you are working with enterprise environment, you need to check the System event log for Netlogon events (such as 5827 and 5828). These events can indicate that a device is using an insecure/incompatible Netlogon secure channel config following Microsoft’s enforcement of secure Netlogon RPC.

This is particularly relevant when the affected system is a legacy device, NAS, appliance, or third-party implementation rather than a standard Windows domain member.

In cases mentioned above, repairing the computer account password/rejoining the Windows machine to the domain may not resolve the underlying problem. The affected device or its software/firmware may need to be updated in order to support secure Netlogon communications.

Rejoin the Failed Computer 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. Note that this requires rebooting the computer at least twice.

Steps to unjoin and rejoin domain manually

1. Ensure that you have access to an approved local admin account. In enterprise environments, you should use Windows LAPS/your organization’s privileged-access solution in order to retrieve/manage the local admin credentials rather than manually setting a shared local Administrator password;
   Enterprise note. If the device is managed by Windows LAPS, you should retrieve the current managed local admin password through the organization’s approved management system before starting the domain rejoin procedure. Do not manually replace a LAPS-managed password unless your organization’s procedures specifically require it!
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.

Rejoin domain using PowerShell commands

The same task can be done using two PowerShell commands:

1. Leave the domain and force the host to reboot:
   

   Remove-Computer -UnjoinDomainCredential THEITBROS\AdminAccount -PassThru -Verbose -Restart

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

   Add-Computer `
   -DomainName theitbros.com `
   -Credential (Get-Credential) `
   -Restart

Note. Add-Computer and Remove-Computer are Windows PowerShell 5.1 cmdlets and are not available in PowerShell 7. If you are using PowerShell 7, open Windows PowerShell 5.1 (powershell.exe) to perform the domain unjoin/rejoin operations shown below.

Root Causes versus Prerequisites for Authentication

Validate Kerberos Authentication State

Usually, Kerberos issues do not break the secure channel itself. However, they can prevent successful domain authentication and produce symptoms similar to trust relationship failures.

You can use the following commands to inspect and troubleshoot Kerberos authentication.

In order to view cached Kerberos tickets, use the command:

klist

To remove all cached Kerberos tickets, run:

klist purge

To sync time with the domain hierarchy, run the command:

w32tm /resync

Why it’s important?

Keep in mind that Kerberos authentication can fail even when the secure channel is healthy. Here are the most common causes:

• excessive time skew between the client and DC
• expired/corrupted Kerberos tickets
• DC authentication problems

In case Test-ComputerSecureChannel reports that the secure channel is healthy but users still cannot authenticate, you need to check the Kerberos state and time sync before rejoining the machine to the domain.

Issue layer	Root cause examples	Symptoms	Recommended tools/fix
Secure Channel (Netlogon trust)	Machine password mismatch, stale secure channel state, failed password rotation, VM snapshot restore	“Trust relationship failed” error, logon failure for domain users, Test-ComputerSecureChannel = False	Test-ComputerSecureChannel -Repair, Reset-ComputerMachinePassword
Machine account state in AD	Deleted/recreated computer object, duplicate computer accounts, SID mismatch	Repair fails, persistent trust errors even after reset, inconsistent AD object behavior	ADUC verification, delete/rejoin domain
Domain connectivity layer	DNS misconfiguration, DC unreachable, routing/firewall issues	Cannot locate domain, slow logon, secure channel test fails intermittently	nslookup, Resolve-DnsName, Test-NetConnection, fix DNS/DC path
Kerberos authentication layer	Time skew (>5 min), ticket issues, Kerberos policy failures	Logon failures despite valid secure channel, authentication errors in logs	w32tm /resync, klist purge, NTP config
Replication/multi-DC inconsistency	Stale machine password on some DCs, replication latency, partial updates	Intermittent trust failure depending on DC used	repadmin /replsummary, nltest /dsgetdc, wait/fix replication

Note. Primarily machine account identity mismatch and secure channel desynchronization breaks the secure channel. The other issues may prevent authentication but they don’t break the trust relationship itself.

Computer account passwords are periodically rotated by the domain. They are stored both locally and in AD. On reconnect, the secure channel is validated and the machine account password may be resynchronized if trust is intact.