I woke up to a call this morning that many (but not all) of the office PC's could not access their network shares. These PC's were having issues logging in as well.

The error message is basically that these PC's had lost the trust relationship with the Domain Controller.

Some PC's got restored randomly over time we some combination of reboots and just waiting.

I have no idea what the heck is going on here. We have a small office - 10 PC's mostly running Vista and a single Windows 2003R2 server. Everything was working fine for the past several weeks, and there haven't been any changes to speak of.

UPDATE: After checking out the logs, it turns out my network topology is buggered. The logs on my local server, the PDC, were inconclusive. But the client machines were littered with errors in the logs referring to kerberos problems with a different server. It turns out we have a satellite office running Win2003 Server, and the that server should not really have anything to do with the local office, other than maybe backup replication services. But for some reason, the trust relationship broke off with the satellite server, and my clients are somehow using that for authentication and kerberos tickets. Clearly, this is over my head (we outsource system administration) and will have to get someone to look at it.

  • Ooo, ouch mate. Am very sorry to hear that, have been in the same boat before. Glad I could help, and good luck! Commented Sep 4, 2009 at 15:36

3 Answers 3


I would highly suggest checking the System, App and Security logs on the local 2K3 server, (provided it's your DC as well?) If it's NOT your DC, check on the local machines to see what DC they're authenticating against. Check the logs on the local machines too, that could shed some light on the issue.

Were there any changes made on either the domain, or the local network the night previous? Any remote software deployed via central location such as Altiris, etc? Off the bat, not knowing your network I'd suggest that someone or something changed on your domain and possibly didn't fully replicate to your office there.. Or, went wrong entirely.

Also, check replication, global catalog status, etc. If reboots are "bringing them back", it sounds like it might just be a case where your machines can't find the DC to authenticate against, etc..

Any more info or details about the domain/network setup you can share?


Are these PC's joined to the domain? If they are verify that their time is set to the same as the server.

  • Yes, all PCs joined to the domain. Out of curiosity, what would cause their clocks to go out of sync overnight?
    – Ankur Goel
    Commented Sep 4, 2009 at 14:59
  • 1
    @Ankur - You should look at Windows event log on DC and clients.
    – alexy
    Commented Sep 4, 2009 at 15:05
  • bad battery on the motherboard will kill the clocks if power went out or power strips cut power to the systems. Clocks skew too far and AD will stop seeing them as proper clients. Part of the Kerberos thing. Commented Sep 4, 2009 at 15:07

Microsoft has the ridiculous assumption that DCs can always talk with each other. If you have a DC at a satellite office, and the link goes down at the wrong time, the kerberos keys will get out of sync, and your clients may or may not be out of sync as well. Fixing this is a big pain, we had to log a support call with Microsoft. In our case, after we had it fixed, we set a group policy to prevent the kerberos keys from changing.
Do this through:

Computer Config -> Windows Settings -> Security Settings -> 
   Local Policies/Security Options -> Domain Member -> 
      Domain member: Disable machine account password changes = Enabled

Supposedly this reduces security (in case someone intercepts your kerberos key and cracks it), but personally I don't see this as a big risk.
Waking up to an office not able to login is bigger risk.

You must log in to answer this question.

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