Domain Trust Failed After a Month Offline? Check First

A laptop sits off the VPN for six weeks, comes back, and the user cannot log in with a domain account. The error mentions a trust relationship, so someone resets the computer account, or forces the user onto full tunneling, and the problem appears to go away. Neither action proved what was broken. A Windows member can stay offline well past the usual machine-password interval without automatically losing trust, so the first job is to separate a reachability failure from a real secret mismatch.

The error looks like trust, but three states look alike

A user may sign in with cached domain information, the workstation may be unable to locate a domain controller, or the member and the domain may genuinely disagree about the machine account. Only the third is a broken trust relationship in the strict sense.

AD replication health is a fourth observation, and it is not about this workstation at all. It describes agreement between domain controllers, and a healthy replication dashboard does not prove that this machine's local secret matches its computer account.

The familiar 30-day default is a change policy, not an offline expiry deadline. Microsoft's machine-account password explanation describes a coordinated change process, and an organization can configure a different interval.

A VPN icon proves nothing about the secure channel

Connectivity has to be good enough to reach domain services before any test means anything. That means the intended domain DNS resolver, a locatable controller, reachable authentication services, and a clock that is close enough for Kerberos.

Full tunneling can be a perfectly valid design here. Changing to split tunneling is not a prerequisite for a healthy domain relationship, and treating it as one turns a diagnosis into an architecture change. Check which controller the workstation actually chooses, and keep that name with the error.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Record the DNS server, the resolved controller, and the exact error text. A VPN client that reports connected tells you the tunnel exists, not that the domain path works. A controller that answers on the Kerberos port but not on the directory port is a firewall finding, not a trust finding.

Test the member before you repair it

On an authorized Windows domain member, Test-ComputerSecureChannel -Verbose is a read-only check of the channel between the machine and the domain. Run it in the machine context you are investigating, not from a domain controller, which has a different role and different recovery rules. Capture the output and the exit status rather than the word pass or fail. If the cmdlet is missing on that build, the module is a separate problem.

The result still needs context. If the machine cannot reach or authenticate to the chosen controller, a failed test is not independent proof that an offline password expired. Keep the actual error and the controller used, and repeat the test once the path is known good.

Correlate Netlogon events on the member and on the relevant controller around the incident. Preserve the machine name, the source address, the time, and any account-change evidence. Another user's successful login, or a healthy controller dashboard, cannot substitute for this machine's exchange.

Repair only the relationship you proved

Once connectivity is stable and an administrator has confirmed that a repair is appropriate, the cmdlet's -Repair mode with authorized credentials is one supported member-workstation operation. It changes the relationship, and it is not another read-only test.

Keep an approved local recovery account and a management path available before the change. Domain controllers have a different recovery role and must not be treated as ordinary workstations by this procedure. Use the organization's recovery workflow instead of running several reset tools in sequence and hoping one of them is the right one.

After the repair, verify a fresh secure-channel test and the original domain operation. Preserve user profiles and application state, and do not make remove-and-rejoin the first unexplained action.

What to check when the failure returns

If the failure comes back, look at rollback, duplicate identity, and the timing of account changes rather than resetting the same account again. A restored image, a snapshot, a cloned machine identity, or a computer-account reset performed elsewhere all deserve investigation.

A temporary successful reset is useful recovery evidence, but it is not proof that an intermittent VPN caused the original mismatch. The next occurrence is the one that tells you whether the cause was ever removed.

Write the controller, the DNS server, and the test output into the ticket. That record is what distinguishes a real trust failure from a laptop that simply could not find the domain.