What causes a workstation to lose trust with the domain controller?
I've received the error several times on Windows 7 Workstations and Laptops where it loses trust with the domain controller, and I know how to fix it, but why does it do that?
You probably already know this, but bear with me.
Computers have passwords in AD, just like users. We don't know our computer's password, and it changes regularly via built-in logic.
The short answer is that the computer's password is no longer valid, and therefore AD doesn't trust this machine for logins any more.
Why? How? Lots of things cause this. Something interfered with the password change process, or caused the machine to revert to an old password. Possible culprits include:
- Restoring from backup.
- Being powered off long enough for the password to expire, followed by network issues.
- General intermittent network issues with poor timing.
- Viruses, malware, etc.
- More things that aren't occurring to me at the moment, probably.
I hope that helps.
Extending on Katherine's answer:
A workstation will lose trust with the domain controller if its account has been overwritten. It is entirely possible (with the right permissions) to add a computer with a name that already exists in the domain, but this will cause the computer that was previously known as that name to lose trust with the Domain Controller.
A reason can be clock drift. If the workstation clock drifts more than 5 minutes away from the server's, it will lose connection to the Domain. This may come from flaky hardware, or when the system is powered off for quite a long time, or sometimes when a laptop is often away from the network, etc.
The AD computer password process (documented here) hasn't changed much and is certainly not the root cause of broken schannel issues. (in fact it's the CLIENT that changes the password and the password is exempt from the password expiration policy. Now depending on the client OS is where things get interesting. 1 reason for lockout is XP. If it's XP and below the client will change it's password - and then try to communicate the new password to the DC. In 7 or above the client won't try until it has a connection to a DC. Domain replication issues can cause schannel failures. The most common casue is reimages of a system where the same name was reused. Time sync issues can also cause problems with schannel, and in most cases you can evaluate what happened (if you are so inclined) by enabling netlogon logging (https://support.microsoft.com/en-us/kb/109626) and examining the logs for why the schannel failed to setup. Failing to sysprep an image seems to also cause a problem ( I haven't figured out exactly why but a disjoin and rejoin seems to always resolve the issue)