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.

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