| Previous | Next |
| ERROR_TRUSTED_RELATIONSHIP_FAILURE | RPC_S_CALL_IN_PROGRESS |
ERROR_TRUST_FAILURE
The network logon failed at the trust-validation stage.
ERROR_TRUST_FAILURE is Win32 error 1790 (0x6FE). It is a broader trust-related network-logon failure than the more specific missing-secret, missing-account, workstation-trust, or trusted-domain codes nearby. The value must be interpreted with the caller, account domain, resource domain, domain controller, authentication package, and event logs; it should not be presented to users as proof that their password is wrong.
Possible failure domains
- the workstation secure channel is unavailable or inconsistent
- an interdomain or forest trust cannot validate the account path
- domain-controller discovery, DNS, time, or network connectivity fails during logon
- the machine contacts stale or partially replicated directory state
- security policy, selective authentication, or SID filtering rejects the trust traversal
Context required for interpretation
Record local computer, user and service account domain, target server and domain, logon type, authentication package, domain controller, site, source IP, time offset, status and substatus values, Netlogon/Kerberos/LSA events, and the immediately preceding specific error if available. Do not collect plaintext passwords or reusable tickets.
How to narrow the cause
Determine whether local logon, same-domain network logon, and cross-domain access fail in the same way. Test domain-controller discovery and secure-channel health, then inspect trust direction and resource authorization. This sequence separates workstation identity from interdomain trust.
Correlate client, target server, and domain-controller events by timestamp. If only one controller produces 1790, investigate replication, DNS site selection, and that controller’s services. If many clients fail after a policy or network change, avoid repairing machines individually.
Resolution strategy
Repair the identified trust, secure channel, DNS, time, replication, or policy issue through supported administrative tools. Retry authentication only after state changes or transient connectivity recovers. Repeated credential prompts can lock accounts and obscure the original trust error.
Applications should surface the target and domain context and preserve native status/substatus. Monitoring should aggregate failures by trust path and controller so an infrastructure incident is not misclassified as hundreds of user mistakes.
Difference from invalid credentials
Bad username or password results concern account credential validation. Error 1790 says the network logon failed in trust processing. It is also less specific than 1788 or 1789; when those values are available, retain them rather than mapping everything to 1790.
Example
A service in Domain A accesses a resource in Domain C through a forest trust. Users can log on locally, but cross-forest requests return 1790. Correlated domain-controller events show the trust path blocked by a recent selective-authentication change; correcting that policy restores access without resetting passwords.
References
- Microsoft: System Error Codes (1700–3999)
- Microsoft: Primary and trusted domains
- Microsoft: Secure channel diagnostic data
Looking for a different code? Search another status or error code.