- Enable AppLocker on Windows 10 Pro and Windows 11 Pro with PowerShell - Thu, Jun 30 2022
- Restore BitLocker-encrypted drives from image backup - Thu, May 19 2022
- When the trust relationship between a workstation and the primary AD domain fails - Wed, May 18 2022
Why the trust relationship failed
Technically, a domain trust relationship is established when a machine joins the domain and is maintained automatically from then on. When the machine joins the domain, a machine password is created that the domain controllers use to authenticate the machine.
This password automatically changes every 30 days. One reason why the trust relationship might fail is that your domain controllers have replication problems and are no longer in sync. For instance, while only the new password is valid on DC1, the old password is still active on DC2. As soon as your client contacts DC2 for logon, it will throw that error. Since you cannot proactively prevent replication problems, this will not be addressed in this article.
The second more common reason for this error surfaces when you restore a domain-joined Windows from an image backup, and the backup was created before the last password change. As said, the password changes every 30 days; thus, if you create a backup on day 29, the password will already be expired if you restore the next day. If you then try to log on with a domain account, you will receive this error message:
The error message may vary depending on your Windows version. In Windows 11, you may even be able to log on, but then the network tray icon will display unidentified network. You may still be able to access domain resources, but since the firewall profile is not the domain profile, you'll definitely run into various issues.
Avoiding the trust relationship problem
To avoid the workstation losing trust with the Windows domain, you can use the command line tool nltest.exe right before imaging. It can change the machine password so you know for sure that this image can be restored at least 30 days after its creation:
Nltest.exe /sc_change_pwd:dom.local
We cannot change the fact that system passwords in system images expire, but we can at least make sure that the restore works without issues within the 30-day period.
Restoring the trust relationship
When it comes to restoring the trust relationship, a simple trick is to disconnect the network cable immediately after the backup has been restored. Simply log on with any administrator account using cached credentials. To re-establish the trust relationship, enter this command on an elevated PowerShell:
reset-computermachinepassword –credential yourdom\resetaccount
This method will only work if an admin has previously logged on and their credentials are in the cache. The domain account "resetaccount" will not need to be admin on the machine in question, nor be domain admin. However, it needs to hold the privilege to reset machine account passwords on the computer OU (or on that single computer object respectively).
If, however, no admin credentials are in the cache, you can use only a local administrator account. Perhaps you didn't create a local admin account and the built-in administrator account is disabled—what now?
The solution is to boot a windows setup and activate the local administrator account. We'll use the command line; to open it, just press Shift-F10 at the setup language selection prompt.
To make this easier, you can save the following lines to activate.bat on a USB drive and launch it:
reg load HKLM\TEMP c:\windows\system32\config\sam for /f "tokens=3" %%a in ('reg query HKLM\TEMP\SAM\Domains\Account\Users\000001F4 /v F') do set str=%%a set str=%str:2000011=2000010% reg add HKLM\TEMP\SAM\Domains\Account\Users\000001F4 /v F /t REG_BINARY /d %str% /f reg unload HKLM\TEMP
This script activates the local administrator account. If you know its password, you are good to go now, but if you don’t, you need to follow this procedure:
At the command prompt, run this command:
reg load HKLM\TEMP c:\windows\system32\config\sam
Open regedit and navigate to this location:
HKLM\TEMP\SAM\Domains\Account\Users\000001F4
Double-click the V-value, navigate to the position in the next screenshot, and replace the following positions marked in yellow with 00.
What have we just done? These two values tell the system how long the LM/NTLM password hash of the built-in administrator account is, and we zeroed them, so the system thinks the password is empty.
Finally, at the command prompt, use:
reg unload HKLM\TEMP
Then restart, and you can now log on as built-in administrator without a password and reset the machine password. Afterwards, disable the built-in administrator again.
you could also unjoin the domain and rejoin. You would also need admin cached creds (domain) for this.
Sure, but that will add two reboots to the process that I could do without.
Actually only one Reboot is required. When dejoining the domain and asked to Reboot, just don’t and join again, then reboot. This will re-establish the domain join and work.
Tony, Jakob, it seems you think that the article is suggesting a complicated method to an easy problem that can be solved by disjoining and re-joining. No, the article shows you the quickest way to get going again for each situation. And when you could do without a reboot, you would prefer that, wouldn’t you? So disjoining and joining again takes more time and should not be preferred.
Well i get what the article is about and it’s great! Would also prefer no reboot of course..
But in situations where the trust relationship is broken because of either a restore, Azure migrate situation or something else that already has reboots/startups baked into the situation, we are just talking about an alternative quick-fix here.
If one can live with i single reboot to solve the issue, it is pretty easy to log in, unjoin, rejoin, reboot.. It’s only an alternative if the situation fits of course 🙂
if the device can not join is server Microsoft Exchange 2013. is manage to fix problem can do with the above solution ?
is there any solution above affected to that server Microsoft Exchange
Hi Rizan. The above tutorial is no cure for “cannot join”. Use the forum here, open a thread, offer details what error messages you see when trying to join.
This article is great, but I’m stuck in an infinite loop of not being able to elevate at command prompt, PowerShell, or WinRE command prompt. Booting into WinRE is looking to “sign in as an administrator, but there are no administrator accounts”.
Any further ideas? Btw, I’m free to reboot as many times as is needed.
Thanks in advance.
Hey Joe.
Boot Windows Setup, it will not ask your for any credentials. Will edit my tutorial accordingly.