Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

One of our domain controllers clock drifted way out of sync with the rest of the network (thanks to me forgetting to turn off VMWare's time synchronisation), which caused a whole bunch of servers to lose their ability to authenticate, given that kerberos requires close time synchronisation between servers.

I manually logged onto it, fixed the clock to the correct time, but it took more than 15 minutes for authentication to start working again (this was a problem, as it was a bunch of terminal servers with people waiting to start their work).

Further information: While the clocks were out of sync, users were getting "there is a time difference" message and their logon was refused. However, after syncing the time, this message went away, but nobodies passwords would work, they were just rejected as invalid. Waiting 15 minutes made them all work again.

In case this happens again, how can I speed up the time taken between putting the clocks back in sync and having normal authentication again?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

w32tm /resync should do the trick. This command will resync the time on the local computer to it's time source, which in an AD domain should be the authenticating DC or the PDC emulator. Running w32tm /resync /computer:COMPUTERNAME will send the resync command to the remote computer specified by COMPUTERNAME (in case you're unable to log on to the computer whose time needs resyncing).

EDIT: I just realized this might not actually fix the problem. After reading your question again, it sounds like the local clocks were already back in sync with the domain hierarchy. My apologies if this answer doesn't help.

share|improve this answer
    
And will this also make authentication work instantly? Admittedly I did reset the time by hand (my only memory of time is from the net time command, which I believe has been depreciated), so if I had used this method, authentication would have come back straight away? –  Mark Henderson Aug 16 '11 at 23:34
    
I'm assuming it would but I may have misunderstood the question slightly. Was the time manually resynced on member servers after you corrected the problem on the DC? If not, then I'd say this answer probably would have solve the logon problem. –  joeqwerty Aug 16 '11 at 23:41
    
The member servers all had the correct time, only the DC had the incorrect time. It was all in all a very messed up situation. –  Mark Henderson Aug 17 '11 at 0:09
    
Yeah, I was just trying to produce the same problem in my environment and haven't been able to do so. –  joeqwerty Aug 17 '11 at 0:18
    
I only demo'ed this with a single DC VM and a single member server VM but I was unable to repro the 15 minute problem, too. I could get logons on the member server to fail but, when I fixed the time on the DC, logons on the member server began to work properly. I'm heartily confused as to what you saw. –  Evan Anderson Aug 17 '11 at 2:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.