What causes a workstation to lose trust with the domain controller?
772
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?
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.
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)
The other way would be to use ADUC and reset the computer account (if it just got out of sync with the domain) simply right-click the computer name and choose "Reset Account" (about 80% of the time this will fix your issue).
The 'why' is that in Microsoft Windows 2003 they extended their directory implementation to include forcing workstations to reset their passwords every 30 days or so. I know it well, it broke a lot of SAMBA installs I was maintaining at the time.
Normally this password reset is all automatic, but I've seen many, many cases when this design just doesnt work. When I turn off a notebook for a while, then try and login with a non-cached account, I immediately receive that error message no matter which post-2000 Microsoft OS I use.
So the easiest way to keep a network working transparently in this fail-mode designed situation is to modify or turn off that policy setting on the Domain level: Group Policies/Windows Settings/Security Settings/Local Policies/Security Options, then look for:
Domain member: Maximum machine account password age
Domain member: Disable machine account password changes
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:
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)
The other way would be to use ADUC and reset the computer account (if it just got out of sync with the domain) simply right-click the computer name and choose "Reset Account" (about 80% of the time this will fix your issue).
The 'why' is that in Microsoft Windows 2003 they extended their directory implementation to include forcing workstations to reset their passwords every 30 days or so. I know it well, it broke a lot of SAMBA installs I was maintaining at the time.
Normally this password reset is all automatic, but I've seen many, many cases when this design just doesnt work. When I turn off a notebook for a while, then try and login with a non-cached account, I immediately receive that error message no matter which post-2000 Microsoft OS I use.
So the easiest way to keep a network working transparently in this fail-mode designed situation is to modify or turn off that policy setting on the Domain level: Group Policies/Windows Settings/Security Settings/Local Policies/Security Options, then look for: Domain member: Maximum machine account password age Domain member: Disable machine account password changes
I hope this helps.