PDC time sync issue

  • Thread starter Thread starter FFF
  • Start date Start date
F

FFF

Here's my problem:
All win2k clients in my domain are unable to authenticate. The error returned
says time out of sync betw. the server and client.

After logging in as local admin, I run:

net time /domain:mydomain.com /set

which returns access denied.

Strange thing is:

After rebooting the PDC, I can both authenticate and run this command for a
period of time.

The following has been changed before the problem started:

A second server running exch2000 was promoted to domain controller to work
around a recurring crash problem with the previous standalone domain controller.

The machine was dcpromo'd and is now a global catalog server (in AD Sites and
Services) and PDC (this shows up when running the W32tm tool).

any ideas?

tia,

florian
 
Here's my problem:
All win2k clients in my domain are unable to authenticate. The error returned
says time out of sync betw. the server and client.

After logging in as local admin, I run:

net time /domain:mydomain.com /set

which returns access denied.

Strange thing is:

After rebooting the PDC, I can both authenticate and run this command for a
period of time.

The following has been changed before the problem started:

A second server running exch2000 was promoted to domain controller to work
around a recurring crash problem with the previous standalone domain controller.

The machine was dcpromo'd and is now a global catalog server (in AD Sites and
Services) and PDC (this shows up when running the W32tm tool).

any ideas?

tia,

florian
Click to expand...
Hello Florian,

what about the eventlog - any entrys there?


Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
Hello Florian,

what about the eventlog - any entrys there?
Click to expand...
Hey Ulf -

nope, the SysEvt log has nothing related, but logs a failure to start the
w32time server when I try to run the W32tm tool. However, this is documented and
can be avoided by stopping the time server before running w32tm (which then
starts the server at runtime).

I have an SSL certificate installed on the server, not sure how this would
affect kerberos authentication or NTP time sync on port 123.
 
Hey Ulf -

nope, the SysEvt log has nothing related, but logs a failure to start the
w32time server when I try to run the W32tm tool. However, this is documented and
can be avoided by stopping the time server before running w32tm (which then
starts the server at runtime).

I have an SSL certificate installed on the server, not sure how this would
affect kerberos authentication or NTP time sync on port 123.
Click to expand...
Hi Florian,

if the system is not able to start the w32time service it sounds really
buggy. I'd try to "reset" the service by "w32tm /unregister" and "w32tm
/register".


Gruesse - Sincerely,

Ulf B. Simon-Weidner
 
Hi Florian,

if the system is not able to start the w32time service it sounds really
buggy. I'd try to "reset" the service by "w32tm /unregister" and "w32tm
/register".
Click to expand...

I transferred the PDC role back to the original DC for the time being, in order
to allow kerberos authentication across the domain. However, I am still working
on resolving this issue.

A possibility that popped up is this:

If Kerberos authentication references the server's hardware clock for some
reason, the failure would be explicable: the app ClockWatchPro (beaglesoft.com)
shows the motherboard clock stuck at 12:00AM and doesn't allow to synch to
Windows system time.

Actually, it counts up the seconds to the full minute before resetting back to
12:00 AM - I believe a spent battery may be the culprit here.

I will try this to confirm as soon as I can afford to take down the server and
post results.

florian
admin, funnygarbage.com
 
I transferred the PDC role back to the original DC for the time being, in
order to allow kerberos authentication across the domain. However, I am still
working on resolving this issue.

A possibility that popped up is this:

If Kerberos authentication references the server's hardware clock for some
reason, the failure would be explicable: the app ClockWatchPro (beaglesoft.com)
shows the motherboard clock stuck at 12:00AM and doesn't allow to synch to
Windows system time.

Actually, it counts up the seconds to the full minute before resetting back to
12:00 AM - I believe a spent battery may be the culprit here.

I will try this to confirm as soon as I can afford to take down the server and
post results.
Click to expand...

Turns out that may have been a coincidence. Couldn't recreate the BIOS clock
problem after the reboot, however the Kerberos authentication died again as the
CPU load increased with ppl coming in the next morning.

When the problem occurred, the CPU meter was pegged at 100%.

My working theory is now that the kerberos authentication does not make the
"roundtrip" in time due to CPU load/missed interrupts.

Could that also have caused the BIOS clock to display incorrectly in the
ClockWatch App? I did not touch the HW clock, yet it appeared to be set
correctly when I checked it in the BIOS at the next reboot.

florian
 
Back
Top