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?


6 Answers 6


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.

  • 6
    Actually I didn't know that. Thank you explaining it. And yes it does help.
    – leeand00
    Commented May 3, 2016 at 17:15
  • 1
    Password change failure really doesn't affect secure channel failures. You would have to go 60days by default for that to be the issue. Resetting the password will however resolve the issue (at least with the DC you're authenticating with).
    – Jim B
    Commented May 4, 2016 at 0:09

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.

  • Interesting. I'm gonna go with flaky hardware.
    – leeand00
    Commented May 6, 2016 at 2:32
  • 1
    I have had this happen with DC in a single server environment when time source is Hyper-V and Hyper-V is domain joined (due to migration of hosts from old server). Time drifts pretty quickly as they are reliant on each other for time. Easy fix using netdom resetpwd /server:<PDC.domain.com> /userd:<Domain\domain_admin> /passwordd:* and then removing the time integration from Hyper-V so DC can get time from the internet (I like Greyware Automations Windows Time Agent and NTP set to NIST servers).
    – David Sain
    Commented Jul 25, 2022 at 17:22

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).

  • 3
    This isn't really answering the original question. He asked why, not how to fix it. Commented May 4, 2016 at 22:36

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.

  • 2
    Please re-read the OP's question.Your approach to addressing the symptom is anecdotal and does not answer the question. The SE sites are not common forums. Please consider the tour
    – jscott
    Commented May 4, 2016 at 3:40
  • 1
    Your fix treats a symptom and not the root cause. Your fix also severely lowers security in the environment.
    – Daniel
    Commented Jul 4, 2020 at 9:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .