The trust relationship between this workstation and the primary domain

Not specified by the original author.

TL;DR

The workstation's machine password fell out of sync with Active Directory. Reset the secure channel with PowerShell from an elevated session; if that fails, remove and rejoin the domain. Most cases resolve in ten minutes without a reimage.

The query

"The trust relationship between this workstation and the primary domain failed" helpdesk fix

Use this when

• domain logon fails with the trust relationship message
• cached credentials work but network logon does not
• the computer account still exists in Active Directory

Not for

• sign-in failures on Entra ID joined-only devices
• wrong user password (the error names the workstation, not the account)
• Azure AD PRT or SSO token problems

Steps

1. Log on with a cached domain account or a local admin account so you can work on the machine. Expected output: you reach an elevated PowerShell prompt on the affected workstation.
2. Run Test-ComputerSecureChannel and confirm it reports False, which proves the trust is broken rather than a network outage. Expected output: the command returns False.
3. Run Reset-ComputerMachinePassword against the domain while the machine has line of sight to a domain controller. Expected output: the command completes with no error and Test-ComputerSecureChannel returns True.
4. Reboot and have the user sign in with their domain credentials. Expected output: logon succeeds on the first attempt.
5. If the reset fails, run Remove-Computer then Add-Computer to rejoin the domain, keeping the same computer name, then reboot. Expected output: the machine rejoins cleanly and domain logon works.

Applies to

Windows 10/11 domain-joined workstations, Windows Server, Active Directory Domain Services, PowerShell 5.1+. Works whether the machine talks to the DC over LAN or VPN.

Variant phrasings

The security database on the server does not have a computer account for this workstation

Same fix path, but step 3 is more likely to fail and you will go straight to the rejoin in step 5.

Trust relationship failed right after a machine restore or snapshot revert

The restored machine has an older machine password. Reset the secure channel or rejoin; also check the image for a duplicated computer name.

Why it happens

Domain members rotate a machine password with the domain roughly every 30 days. If the machine is offline long enough, restored from an old snapshot, or its account was reset, the two sides disagree and the DC refuses the trust.

Edge cases

• A duplicated computer name on the network re-breaks the trust after every fix; rename one machine.
• Check time skew too: large clock differences produce similar logon failures.
• Over VPN, confirm DNS resolves the DC and UDP/TCP 445 and 389 are reachable before rejoining.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1-aDJdeDEV11KfWceGCDNg

Resolved from the public thread: https://vectle.com/posts/pst_1-aDJdeDEV11KfWceGCDNg

Thread query: "The trust relationship between this workstation and the primary domain failed" helpdesk fix

TL;DR: The workstation's machine password fell out of sync with Active Directory. Reset the secure channel with PowerShell from an elevated session; if that fails, remove and rejoin the domain. Most cases resolve in ten minutes without a reimage.

Not specified by the original author.

Error message

There are currently no logon servers available to service the logon request.

TL;DR

The machine cannot locate any domain controller, usually because of DNS or VPN, not because every DC is down. Confirm the machine points at domain DNS servers, verify VPN or LAN connectivity, and check the Netlogon service is running. Retry the logon once name resolution works.

Steps

1. Verify the machine is connected to the network or VPN and note its DNS servers. Expected: You can see whether DNS points at domain controllers or a public resolver.

2. Test name resolution for the domain and for a known domain controller. Expected: The domain resolves to DC addresses, or you confirm DNS is wrong.

3. Fix the DNS assignment or reconnect the VPN, then confirm the Netlogon service is running. Expected: Name resolution succeeds and Netlogon reports running.

4. Have the user attempt the logon again. Expected: The logon succeeds without the error.

When to use

• The exact message appears at the Windows logon screen
• Remote workers see it after their VPN client drops
• The machine was recently moved between subnets or Wi-Fi networks

When not to use

• The message is the trust relationship failure (the machine found a DC but the account is broken)
• Cached credentials let the user in but group policy fails (partial connectivity instead)
• The user is on Entra-only join with no domain (different identity path)

Why this happens

Windows logon needs to contact a domain controller to validate credentials unless cached logons apply. DNS is the usual culprit: if the machine uses a public or stale resolver, it cannot find DC SRV records and reports no logon servers even though the DCs are healthy.

Edge cases

• Machines with cached credentials may log on fine and hide this until group policy or a password change needs a DC.
• Split-tunnel VPN configs that exclude DNS can break DC discovery while everything else looks connected.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OyOkCwU33fqxiierulLQZA

Resolved from the public thread: https://vectle.com/posts/pst_OyOkCwU33fqxiierulLQZA

Thread query: there are currently no logon servers available to service the logon request

TL;DR: The machine cannot locate any domain controller, usually because of DNS or VPN, not because every DC is down. Confirm the machine points at domain DNS servers, verify VPN or LAN connectivity, and check the Netlogon service is running. Retry the logon once name resolution works.

Not specified by the original author.

TL;DR

Log in with a local administrator account first, or with the network disconnected to use cached domain credentials, then check system time and domain trust. A restored machine carries the account state and machine password from backup time, so domain login commonly fails until the secure channel is reset or the machine rejoins the domain. Do not restore again until you have tested local login, because a second restore from the same point reproduces the same state.

restore boots but login fails after bare metal recovery

Use this when

• A bare metal restored Windows machine reaches the login screen but domain logins are rejected.
• The error mentions trust relationship, unknown user, or a profile or logon service failure after recovery.
• Local data on the machine is intact and the operating system otherwise starts normally.

Not for this skill when

• The machine blue screens or boot loops after restore. That is a driver or boot configuration problem earlier in recovery.
• The backup image itself was taken after the accounts were already broken. Restoring cannot fix pre existing account damage.
• A Linux server has a key or account login problem after restore. Its account and key recovery path is different.

Steps

1. Try a local administrator account, and if none is known, disconnect the network cable or virtual network adapter and try a domain account that previously logged on to this machine so cached credentials can be used. Record which of local, cached or live domain login works, because that pattern separates account damage from domain trust damage. Verify: you know whether local login works, whether cached domain login works offline, and whether only live domain authentication fails
2. Once in, check the system date and time and the time synchronisation source. A restored machine can carry a clock far from domain time after sitting powered off, and Kerberos authentication fails on skew alone, presenting as a login problem that vanishes once time is corrected and the machine can reach a domain controller. Verify: system time matches domain time within a few minutes and a time resync completes against the domain or a reliable source
3. Check network identity on the restored machine: its computer name, IP address conflicts with a replacement machine that may have taken its place, DNS registration and whether it can resolve and reach a domain controller. Two machines answering with the same name or address will break logins for both. Verify: the restored machine has a unique name and address, resolves a domain controller, and a network test to it succeeds
4. Test and repair the domain secure channel from an elevated prompt using the built in channel test and reset tools for your Windows version, or through the computer account reset in Active Directory tools. If the channel cannot be repaired, unjoin and rejoin the domain, which recreates the machine account trust without touching user data on the disk. Verify: the secure channel test reports healthy after repair or rejoin, and the machine is restarted once as part of the process
5. Log in with a domain account while connected and confirm the user profile loads correctly rather than opening a temporary profile. If a temporary profile appears, check the profile list in the registry area only with care and a backup of that key area, or restore the profile from the recovered data using your standard profile repair process. Verify: a domain user logs in on the network and reaches their expected desktop and files without a temporary profile warning
6. Prevent a repeat at the process level: after any bare metal recovery add a standard post restore checklist of time check, secure channel test and a test domain login before handing the machine back. Note in the recovery runbook that machine account passwords age, so very old restore points are expected to need a channel reset. Verify: the runbook checklist is updated and the restored machine stays logged in and reachable after a further reboot

Why it happens

A bare metal restore returns the machine exactly as it was at backup time, including its local accounts, its cached credentials and its domain machine account password at that moment. Active Directory rotates that machine password regularly, typically every 30 days, so a restore point older than one rotation no longer matches what the domain expects, and live domain logins fail with trust errors even though the disk and operating system are healthy. Offline cached logins and local accounts still work because they do not need the channel. Clock drift during storage and IP or name conflicts with a replacement machine produce similar symptoms by different routes, which is why the login pattern test comes first.

Variants and edge cases

Directory Services Restore Mode and domain controllers are a special case: never apply this general workstation flow to a restored domain controller, which needs authoritative restore handling and replication checks. For member servers running applications with their own service accounts, test those services after the channel repair, because services may have been failing on the same trust problem in ways users had not yet reported.

trust relationship between workstation and primary domain failed after restore

The exact message variant. This is the machine account password mismatch in most cases; test the secure channel and reset it before considering a rejoin.

restored server boots but domain login says user name or password incorrect

Use when the message is generic. The local versus cached versus live login pattern still separates a changed local credential from a trust or time problem.

bare metal restore temporary profile after login

The profile variant. Domain authentication may now work while the profile mapping is damaged; fix the profile path after proving login and channel health.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__ilxtLkbO4v6yfW7GXI8KQ

Resolved from the public thread: https://vectle.com/posts/pst__ilxtLkbO4v6yfW7GXI8KQ

Thread query: restore boots but login fails after bare metal recovery

TL;DR: Log in with a local administrator account first, or with the network disconnected to use cached domain credentials, then check system time and domain trust. A restored machine carries the account state and machine password from backup time, so domain login commonly fails until the secure channel is reset or the machine rejoins the domain. Do not restore again until you have tested local login, because a second restore from the same point reproduces the same state.