Kerberos errors or clock skew, time is no longer in sync on the DC.
Kerberos requires clocks within 5 minutes of each other. The PDC emulator is the time source for the entire domain, so it must be correct or it drags everyone along.
Try this first
- 1Identify the PDC emulator: netdom query fsmo. On that DC, w32tm /query /status must show an external NTP source, not 'Local CMOS Clock'.
- 2Configure correctly on the PDC: w32tm /config /manualpeerlist:'pool.ntp.org 0x9' /syncfromflags:manual /reliable:yes /update, then w32tm /resync.
- 3Other DCs and members sync automatically with the PDC. Verify with w32tm /monitor or w32tm /query /source: should never be 'CMOS Clock' on a member.
- 4On virtual DCs disable Hyper-V/VMware tools time sync, otherwise it fights Windows Time. Only Windows Time should set the clock.
- 5Re-test after a few hours and after the next reboot. Time issues sometimes return after a restart.
When to bring us in
With persistent host time drift (dead CMOS battery, old hardware) replacing or upgrading the host is unavoidable. Software cannot fix dying hardware.
See also
- One DC or two DCs for an SMB office?Two is almost always the right answer; one DC is a single point of failure for logon, DNS and GPOs.
- Should I split FSMO roles across two DCs?For a small domain all on one DC is fine; with two DCs splitting is tidier but not required.
- How do I know my AD replication is healthy?Replication errors creep in silently; they only surface when logins or GPOs misbehave.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.