What does Windows error code 1789 (ERROR_TRUSTED_RELATIONSHIP_FAILURE) mean?

 
Previous Next
ERROR_TRUSTED_DOMAIN_FAILURE ERROR_TRUST_FAILURE

ERROR_TRUSTED_RELATIONSHIP_FAILURE

The workstation-to-domain trust relationship is broken.

ERROR_TRUSTED_RELATIONSHIP_FAILURE is Win32 error 1789 (0x6FD). A domain-joined computer and Active Directory maintain matching machine-account credentials for their Netlogon secure channel. This result commonly means those credentials or identities no longer agree, even though the computer object and local join information both exist. Cached user logon may still work, which can hide the fault until a network operation requires the domain.

Typical causes

  • a virtual machine or physical image was rolled back to an older machine-account password
  • the computer account was reset, restored, or recreated independently of the workstation
  • duplicate cloned machines use the same domain identity
  • replication, DNS, time, or connectivity prevents contact with a domain controller holding current state
  • rename, rejoin, disaster recovery, or snapshot automation was interrupted midway

Evidence before changing the account

Collect computer and domain names, domain controller selected, secure-channel test output, machine-account password-change events, object GUID, last password-set time, DNS configuration, time offset, VM clone or snapshot history, Netlogon events, and whether multiple hosts claim the same name. Keep local administrator and disk-recovery access available before repair.

Diagnostic sequence

Verify domain DNS, time, and domain-controller reachability first. Test the secure channel from a local administrative session and compare results against more than one healthy controller when replication is suspected. Determine whether the problem began after restore, clone, account reset, or rename.

Check for duplicate machine identities before resetting credentials; repairing one duplicate can break the other. Confirm the corresponding computer object is the intended object and is enabled. Cached interactive logon success does not prove the secure channel is healthy.

Supported repair

Use Test-ComputerSecureChannel repair or reset the machine password with authorized domain credentials, then verify Netlogon events and resource access. If state is too inconsistent, remove and rejoin the computer according to organizational procedure while preserving profiles, certificates, encryption keys, and service dependencies.

Virtualization workflows must clone from generalized images and avoid reverting domain members across machine-password changes without a coordinated recovery plan. Monitor recurring failures by host because repeated repair indicates an underlying snapshot or identity-management defect.

Difference from missing trust objects

Error 1786 means the local trust secret is absent, and 1787 means the domain lacks the computer account. Error 1789 usually indicates an existing workstation/account pair whose secure-channel credentials no longer match or cannot be validated.

Example

A domain-joined VM is restored from a month-old snapshot. Cached logon works, but network access returns 1789 because Active Directory has a newer machine password. Administrators repair the secure channel once and change the backup procedure so future restores include a documented trust recovery step.

References


Looking for a different code? Search another status or error code.