Active Directory Operations and recovery
A workstation's broken trust relationship
Check the member's DC and machine-account state before repairing its secure channel.
An offline computer does not simply time out of the domain
The Netlogon service on a member initiates machine-account password changes. A powered-off computer cannot initiate them. Being offline for more than the normal password-change interval is not, by itself, an explanation for a broken secure channel.
Investigate restored machine images, duplicated computer identities, computer-account resets or replacements, directory replication and which DC the member reached. Microsoft’s machine account password explanation describes the client-initiated process.
The local machine secret and the credential held by the AD computer object have to agree for Netlogon to establish the secure channel. Recreating an AD object with the same name won’t preserve its GUID/SID or restore that agreement. A password timestamp is useful context, but it doesn’t compare the two secrets.
Check the member’s selected DC
On the affected domain member, in an elevated Windows PowerShell session:
nltest /dsgetdc:contoso.com
nltest /sc_query:contoso.com
/sc_query reports the channel’s state as known to Netlogon. Preserve the status code and selected DC. Test DNS, time and connectivity before concluding that a password mismatch is the only possible cause. A stale account on one DC can produce different results from a healthy replica.
Be careful with the similarly named /sc_verify: it is not purely a read. If its check fails, it can remove and rebuild the channel, so don’t include it in the initial collection. The Nltest reference distinguishes query, verification and reset behavior.
Test without requesting repair
Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Server 'dc1.contoso.com' -Verbose
This cmdlet is for domain member computers. It can report false errors on a DC; do not use its result as a DC-health verdict. The cmdlet reference documents that limitation.
Compare a deliberately selected DC with the member’s normal discovery path. If one works and another fails, investigate replication and DNS and DC Locator before repeatedly changing the member’s password.
Inspect the computer object’s history
From an administrative directory session, compare the same computer object on the implicated replicas:
Get-ADComputer -Identity 'WS01' -Server 'dc1.contoso.com' `
-Properties pwdLastSet,whenCreated,whenChanged,PasswordLastSet |
Select-Object ObjectGUID,SID,DistinguishedName,
whenCreated,whenChanged,PasswordLastSet,pwdLastSet
If object identities match but state differs, inspect attribute replication metadata. A very recent whenCreated or changed GUID can point to account recreation; a machine restored from an earlier image can instead retain an older local credential. Neither observation alone identifies who performed the change, so correlate directory auditing and the imaging/restore history.
On the member, keep the System events from Netlogon and the full error text. Check whether the operation failed before finding a DC, during channel authentication or only when accessing a particular resource. A user credential failure to a share can have another cause even if a trust-relationship message appears elsewhere.
Repair is a credential change
After confirming the member and intended computer object, an authorized administrator can run this repair on the affected member:
$credential = Get-Credential
Test-ComputerSecureChannel -Repair -Server 'dc1.contoso.com' `
-Credential $credential -Verbose
Use credentials with the required rights to that computer account. Then repeat the test and verify the affected sign-in or application operation. Do not run this across a fleet solely because accounts have old timestamps.
Run the command locally on the affected member, or through an administrative session whose target has been confirmed. Running it on the management workstation repairs or tests that workstation instead. If DNS is still selecting the wrong directory or an old DC state remains unreplicated, a successful one-DC repair can leave intermittent failures.
nltest /sc_reset also rebuilds a channel. Query and reset are different operations; keep the state-changing command out of the initial collection pipeline. DC machine-account recovery requires a DC-specific procedure, including its KDC and replication context, rather than this member recipe.
Preserve the identity when investigating
Removing and rejoining a computer can hide the original failure and disturb its permissions or management relationships. Before taking that route, collect the member’s Netlogon and System events, computer object GUID, selected DC and relevant replication results. Even if repair succeeds, find out why the secrets diverged, particularly when a restore or duplicate machine image was involved.