There are a few common reasons why this happens.

  1. A computer with a duplicate name was joined to the domain. This will cause the original to no longer have a trust relationship with the domain, since its computer account is now effectively the account for the new machine with the duplicate name.

  2. Time sync is screwed up. You won't be able to log in if the time is more than 5 minute off. Kerberos relies on time being at least in the same ballpark on the clients and servers. Make sure that your DC holding the PDC Emulator role is set as a reliable time source and that all of your other DCs sync from it. Also make sure that there are no alternate time sources configured for your clients via GPO or local policy. The clients should sync time from the logon server.

  3. The computer account was reset or the password came out of sync. Computers log into AD just like users do, and they have a password. This password is changed at a regular interval behind the scenes. If you have replication problems and a computer changes the password on one DC and then later tries to log into another and replication failed for whatever reason, your machine won't be trusted for logon on, since the computer password differs between the client and logon server.


There are, of course, other edge cases why this happens. These are the most common and are where your troubleshooting should begin. There's no script, GPO, or magic fairy dust to sprinkle, since there isn't a normal reason for this to happen.


If it happens more than every once in a blue moon, you need to track down the root cause to determine what's breaking the trust relationship. There's no magic policy or script to do it for you.

You'll want to make sure it's not some script or other administrator deleting these machines form the domain, that the machines aren't being "tombstoned," and that your AD is healthy (dcdiag, etc). Your basic AD administration/troubleshooting steps, in other words.