Windows: repair an AD trust relationship without leaving the domain

Check DNS, time, and the secure channel before repairing an Active Directory member computer with PowerShell, validation, and recovery planning.

01

Repair the secure channel, not the workstation

A trust relationship error can prevent domain sign-in while Windows otherwise starts normally. A targeted secure-channel repair can avoid leaving and rejoining the domain, but only after identifying the cause.

This guide covers Windows workstations and AD DS member servers. It does not repair an interdomain trust or Microsoft Entra registration. Domain controllers require a separate procedure.

02

Understand what can diverge

The device and Active Directory maintain a secret associated with the computer account. A restore, incorrect cloning, or AD inconsistency can break that relationship. A long offline period alone does not prove that the secret expired.

Microsoft distinguishes a device with an older secret from AD holding an older value. In the latter case, investigate directory replication and restoration before repairing clients. Simultaneous failures on several machines warrant an AD investigation.

03

Prepare recovery access

Before changing anything, confirm working local administrator access, console or out-of-band access, and the applicable BitLocker recovery procedure. An authorized person must be able to retrieve a LAPS password; do not copy it into the incident log.

Use elevated Windows PowerShell 5.1 for these examples. Testing requires local administrative rights. Repair also requires an AD identity authorized to reset the targeted computer account password. Delegate the needed right within scope instead of granting Domain Admin.

Arrange a pilot device, a change window for service-hosting servers, an appropriate backup, and an owner. Do not rely solely on a remote session that could be lost. These AD DS commands do not require an additional Entra subscription; normal Windows licensing requirements still apply.

04

Step 1: confirm role and symptoms

Read the role before continuing. DomainRole 4 or 5 identifies a domain controller: stop this procedure. A device outside the domain has no AD DS channel to repair.

Record the exact message and System/NETLOGON events around the failure. Event 3210 is a documented lead, not a reason to reset every machine. Protect internal names in diagnostic output.

# Read-only, on the affected device
Get-CimInstance Win32_ComputerSystem |
  Select-Object Name,Domain,PartOfDomain,DomainRole
Get-WinEvent -FilterHashtable @{
  LogName='System'; ProviderName='NETLOGON'
  StartTime=(Get-Date).AddHours(-4)
} -ErrorAction Stop | Select-Object TimeCreated,Id,Message
05

Step 2: check DNS, network, and time

The device must use resolvers able to resolve AD zones and reach an appropriate DC. A DNS response or reachable TCP port does not prove every AD flow works. Also inspect VPN, routing, and network rules for the actual architecture.

Read time status and synchronization source before correcting anything. A time-related Kerberos error is not fixed by automatically resetting the computer account. The following commands are diagnostic; replace the fictional domain.

# Read-only; fictional domain
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName -Type SRV '_ldap._tcp.dc._msdcs.contoso.com'
nltest /dsgetdc:contoso.com
w32tm /query /status
w32tm /query /source
06

Step 3: test without repairing

Choose a DC with confirmed health and replication. Test-ComputerSecureChannel without -Repair checks the local device channel. True means this test succeeds; it does not validate all applications or policies. False requires examination of prerequisites and errors.

Do not run this test on a DC: Microsoft documents misleading error results in that case. If the computer account was deleted, disabled, or recreated, examine its identity and history before attempting repair.

# Read-only; member computer only
$dc = 'DC01.contoso.com'
Test-ComputerSecureChannel -Server $dc -Verbose
07

Step 4: explicitly authorized pilot repair

Change: after diagnosis and authorization of the change window, run one repair on the affected member. Get-Credential avoids embedding a plaintext secret in the script. Use the appropriate delegated account, then remove the session variable.

Do not automatically chain several reset tools. If the command fails, preserve the error and examine rights, selected DC, and connectivity. If it succeeds, proceed to validation and arrange a controlled restart under the applicable procedure; do not force a remote reboot without preparation.

# CHANGE: one approved member computer only
$credential = Get-Credential -Message 'Authorized AD computer-account repair'
try {
  Test-ComputerSecureChannel -Repair -Server 'DC01.contoso.com' `
    -Credential $credential -Verbose -ErrorAction Stop
} finally {
  Remove-Variable credential -ErrorAction SilentlyContinue
}
08

Validation and a concrete scenario

Fictional example: PC-ACCOUNTS01 fails after a restore. DNS and time are correct, the AD account exists, and DC data is consistent. The test fails, then the pilot repair succeeds. After a planned restart, validate domain sign-in with an authorized test user and access to an internal resource.

Repeat the test without -Repair, review events, and verify expected functions: policy, file share, and business application. Cached sign-in alone does not prove authentication against a DC. Document before/after results and monitor recurrence.

09

Recovery and when to stop

Repair changes a secret: there is no simple Undo button. Blindly restoring an old snapshot can reintroduce the mismatch. Recovery relies on local access, console access, backup, and a procedure coordinated with the AD team.

Stop if the device is a DC, DC data diverges, the computer object is questionable, duplicate names are suspected, or compromise is possible. Rejoining may be necessary in some cases, but must be planned around profiles, certificates, and dependencies; it is not the first response.

Do not disable computer password rotation or weaken Netlogon to hide the failure. For recurring incidents, Active Directory troubleshooting can examine dependencies and the cause; this focused guide does not replace a full assessment.