An AD trust between two domains stopped working and users cannot access resources.
Trusts usually break due to DNS, firewall or an expired trust password. Measure first, then fix, and put logs from both sides next to each other.
Try this first
- 1On a DC on each side run nltest /sc_query:OTHERDOMAIN and netdom verify /domain:OTHERDOMAIN. Read the exact error code.
- 2Check DNS: forward and conditional forwarders must work both ways, plus reverse zones. Test with nslookup -type=SRV _ldap._tcp.dc._msdcs.OTHERDOMAIN.
- 3Firewall check: ports 88 (Kerberos), 389 and 636 (LDAP), 445 (SMB), 3268 (Global Catalog) and the RPC range must be open between DCs.
- 4Reset the trust password if everything else looks fine but Kerberos complains: netdom trust /domain:OTHERDOMAIN /resetonewaytrustpassword (both directions, a few minutes apart).
- 5Test with a test account from the other domain against a share or PC, and check Event Viewer (System and Security) on both DCs for Kerberos and NTLM events.
When to bring us in
In a merger or acquisition where the other side is not under your control, gather logs and involve both AD teams. Trust troubleshooting without access to the other side is almost always a dead end.
See also
- One DC or two DCs for an SMB office?Two is almost always the right answer; one DC is a single point of failure for logon, DNS and GPOs.
- Should I split FSMO roles across two DCs?For a small domain all on one DC is fine; with two DCs splitting is tidier but not required.
- How do I know my AD replication is healthy?Replication errors creep in silently; they only surface when logins or GPOs misbehave.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.