Error 1788 trusted domain failure: forest and external trusts that stop working

Fix it now

Microsoft publishes 1788 as “The trust relationship between the primary domain and the trusted domain failed”. This is a trust between two domains, not one machine’s secure channel. Verify the trust first, and reset the shared secret only if verification fails.

netdom trust corp.example.com /Domain:partner.example.net /Verify /UserD:partner\admin /PasswordD:* /UserO:corp\admin /PasswordO:*
nltest /sc_query:partner.example.net

1. Microsoft describes /Verify as verifying the secure channel secrets for a specific trust relationship. If it succeeds, the secret is intact and the fault is elsewhere.
2. If verification fails, reset the secret with the same command and /Reset in place of /Verify. Microsoft describes /Reset as resetting the trust secret between trusted domains.
3. On a two-way trust, do both directions and confirm each one separately.
4. If verification fails with a domain-not-found error, stop resetting and fix name resolution between the two forests first.

Both sides need credentials. /UserD and /PasswordD are for the trusted domain, /UserO and /PasswordO for the trusting one, and /SecurePasswordPrompt opens a secure credential prompt where a password would otherwise be typed.

If verification now succeeds in both directions and a cross-domain sign-in works, you are done. If not, the next section covers what a trust is made of and which part has failed.

Why it happens

A trust is a pair of objects, one in each domain, plus a shared secret the two sides rotate. If one side is restored or rebuilt, its copy stops matching, and every authentication crossing the trust fails from that moment. That is what netdom trust /Verify is testing when Microsoft describes it as verifying the secure channel secrets for a specific trust relationship, and it is what /Reset puts back.

Authentication over a trust is referral-based. A client asks its own domain controller for a ticket to a service in the other domain, its domain controller issues a referral encrypted with the trust key, and the far domain’s key distribution centre decrypts it and issues the service ticket. The failure surface is therefore four things: the shared key, the ability to find the other side’s domain controllers, the ability to reach them, and the rules deciding which name suffixes route across.

The neighbouring codes divide that space, and one of them is routinely misread. 1790, ERROR_TRUST_FAILURE, is published simply as “The network logon failed”. 1396, ERROR_WRONG_TARGET_NAME, is “The target account name is incorrect”, which points at a service principal name rather than at the trust. 1355 is “The specified domain either does not exist or could not be contacted”, which is name resolution. 1326 is “The user name or password is incorrect”.

1265 is the one to be careful with. Microsoft publishes ERROR_DOWNGRADE_DETECTED as “The system cannot contact a domain controller to service the authentication request. Please try again later.” Older material reads it as a security-compromise warning and infers a key mismatch from it; that is not what Microsoft publishes. Read a 1265 as the system being unable to reach a domain controller for the request, and go and check that it can.

Full reference

The codes

1265 is not a key mismatch. Microsoft’s published text points at reaching a domain controller, so treat it as a connectivity and locator problem rather than as evidence that the trust secret is wrong.

The netdom trust syntax, in full

A worked example from Microsoft’s own documentation, verifying with Kerberos and credentials on both sides: netdom trust MyDomain /domain:devgroup.example.com /verify /kerberos /userd:devgroup\admin /passwordd:* /usero:MyDomain\admin /passwordo:*. The one-way reset example is shorter, because only the trusted side’s credentials are needed.

Where the supported line falls

Microsoft also notes that Windows Server 2019 and Windows Server 2022 use Windows Server 2016 as their most recent functional level. Read the table before accepting anyone’s claim about what a partner domain must be running: the constraint that actually exists is which functional levels a given domain controller release supports, and a Windows Server 2025 domain controller will not sit at the Windows Server 2012 R2 level at all.

Before you delete and recreate anything

Deleting and recreating a trust interrupts every cross-domain authentication while it is down, including scheduled jobs and service accounts nobody remembers exist. Plan a window, tell both organisations, and try /Verify and /Reset first – they are what Microsoft documents for a secret that has diverged.

Selective authentication

Where a trust validates cleanly and specific foreign users are still refused at specific servers, look at whether the trust was created with selective authentication. That configuration deliberately requires an explicit grant before a foreign principal may authenticate to a given computer, so the refusals are the design working rather than the trust failing. It produces credential-shaped errors, which is why it gets investigated as a broken trust; the giveaway is that the failure follows particular target servers rather than particular users or times.

Forest trust or external trust

A forest trust connects two whole forests, is transitive across the domains in each, and supports name suffix routing – which is why /NameSuffixes applies only to forest trusts and forest transitive realm trusts. An external trust connects one specific domain to another and nothing else. If your organisation only ever needs one relationship with one domain, the external trust is the smaller surface. If you find yourself creating a second and a third, you probably wanted a forest trust.

Every code this article covers

Confirm the fix worked

1. netdom trust <trusting> /Domain:<trusted> /Verify succeeds in both directions.
2. nltest /sc_query:<trusted domain> reports success from a domain controller on each side.
3. A user from the other domain reaches a resource that had been failing.
4. dcdiag /test:CheckSecurityError reports no errors on either side.
5. No new 1788 entries appear on either side over a full working day.

Questions people ask about this