"Time difference between the Client and Server"- there's not

[cookiespin]

Beginning 4/19 we have had several users receive the error message "The system cannot log you on due to the following error: There is a time difference between the Client and Server."
We use Active Directory, native mode.
PDC is in time zone GMT-5. Users receiving this error are in 2 different locations, both GMT-4.
net time command shows all are in sync.
Running net time \\pdc /set /y on computers in one location has resolved the problem (although some users have had to reboot rather than just log in). Not all users are affected.
The other location is unable to log in today.
ms knowledgebase has only two articles ref. this error- one says to sync the time (Which we've tried through net time and restarting windows time service). The second is related to surf control web monitoring. We have used this for several years, but an admin installed 4.5 last week on a test box- he's never brought it online. Now this box is unhooked from the network.
Anyone ever run into something like this?
Any trouble-shooting ideas?
Thanks.

 

[SGTRawlins]

I was trying to introduce a client into our network the other day, i was presented with this same error message.

I resolved the issue by manualy changing the time on the client to match that of the server it is connecting to.

Give this a try.

 

[cookiespin]

The time on the troublesome clients is actually already in synch with the server.
I'll try just touching the time in date and time properties box manually rather than forcing the synch and we'll see what happens.
Thanks for the suggestion.

 

[jimrockford]

Are you verifying the client time against the DC they're authenticating to, or against the PDC? The users having trouble sound like they are geographically separated, and possibly all in the same location. I would guess you've got a DC at their location. How's the time set there?

 

[anawrocki]

Forgive me for suggesting the pbvious, but have you verified the day / year?

 

[anawrocki]

Forgive me for suggesting the obvious, but have you verified the day / year?

 

[cookiespin]

Thanks for the suggestions- I wish it was the obvious! But the day/year and time have been correct on all we've checked so far. We do have DCs in two other locations, and these are also synced with the PDC.

 

[tataylor]

We have been having the same kind of time issue since the weekend. All I have been able to determine so far is the fact that it seems to be related to the microsoft security updates that we installed on all of our domain controllers over the weekend. I have not been able to figure out what is wrong or how to correct it. Rebooting domain controllers seems to help it for a while but the problem always returns. I now have seen reference to this issue from several different sources. Microsoft still has nothing on their site about this that I am aware of.

 

[cookiespin]

We ran windows updates over the weekend. The first server to get the updates was the dc in our most trouble-some location.
We went native mode with MSExchange on Monday.

Here's a link to a "known" problem...

http://support.microsoft.com/default.aspx?scid=kb;en-us;321290

We do use images to set up most of our client machines, as indicated by the article. However, this is not new to us, and the errors only began Monday, after the windows updates began to be implemented.
We've implemented this "fix" on a few clients. We'll have to wait and see if it really fixes this issue.
We can "always" get a client logged on by restarting windows time service and rebooting, but the problem comes back.
Anyone heard anything else about windows updates and time synching issues?

 

[cookiespin]

I should have mentioned we also find that rebooting a dc resolves the issue for a time.

 

[phishphreek]

Just had this problem this AM.

It was a xp pro sp1 client on a 2k domain.

I made sure the time was the same on the client as on the server.

Then, I unjoined the client from the domain and then rejoined it to the domain.

Worked perfectly.

Not quite sure why this happens though... it is pretty rare.

You can also try unregistering the w32time and the registering it again...

1. Start->Run cmd.exe
2. net stop w32time
3. w32tm /unregister [ignore error message]
4. w32tm /unregister
5. w32tm /register
6. net start w32time

Hope that helps someone!

 

[cookiespin]

Thanks for all the suggestions.
The windows updates apparently affected how kerberos authentication was handled in AD. It was necessary to change the default maximum tolerance for computer time synchronization value in our AD policy. By default, it was not defined, and our understanding is that prior to the updates the value used was 5 minutes. After the updates, we had to define this value, and now everything works as it should.

 

[tataylor]

Thanks for the info cookiespin. I agree that the issue is exactly kerberos authentication in AD. Not sure what the updates did to hurt this. One thing that I have read is that Microsoft used an expired certificate in the updates. Not sure if this is true or not. Did you just hard code the default maximum tolerance to five minutes or make it a larger value? The way we were able to "resolve" the problem was to remove three of the security updates. However, we believe the problem was really with 835732. Did setting this time value work with out removing any of the updates?

 

[cookiespin]

We, also, believe that 835732 was the culprit, but I hadn't heard anything about an expired certificate. We hard-coded the default maximum tolderance to 5 minutes without uninstalling the updates. No problems since then.
My guess is that prior to the updates, if the value wasn't specified, 5 minutes was used. Maybe the change is truly an improvement overall for how the authentication works and we should be glad that a hard-coded value is now required. It just would have been nice to read something about that before we installed

n.b.Sorry for the delay in this response- email notifications from tek-tips aren't getting through our email gauntlet, so I've changed to use my yahoo account.