To fix NTP sync problems, confirm the time service is running, verify UDP port 123 is open outbound, check that configured servers respond with a valid stratum below 16, and correct any offset above a few seconds manually before letting NTP discipline the clock. Then monitor drift.
Symptoms
- Kerberos or AD logons fail with clock-skew errors above the five-minute tolerance
- Log timestamps across servers disagree by seconds or minutes, breaking correlation
- ntpq -p shows every peer with stratum 16, reach 0, or a leading space instead of *
- w32tm /query /status reports 'Source: Local CMOS Clock' or last sync hours ago
- TLS certificate validation fails on fresh systems because the local clock is in the past
Common Causes
Blocked UDP 123 egress
Perimeter firewalls, cloud security groups or ISP filters silently drop outbound NTP. The client keeps polling but every peer stays unreachable.
Wrong or unreachable server pool
Hard-coded servers that were decommissioned, region-specific pools with poor routing, or internal PDCs that themselves lost sync upstream.
Service stopped or conflicting
On Linux, ntpd and chronyd cannot both bind UDP 123. On Windows, w32time is disabled by group policy or set to NoSync mode.
Excessive initial offset
NTP refuses to step the clock when drift exceeds the panic threshold (default 1000 seconds). The daemon exits or logs 'offset too large' and never disciplines.
Virtualization time source conflict
VMware Tools or Hyper-V Integration Services push host time into the guest while NTP also runs, producing oscillating corrections and unstable offsets.
Step-by-Step Fix
- Capture the current offset and sync state before changing anything
On Linux run timedatectl and chronyc tracking or ntpq -pn. On Windows run w32tm /query /status and w32tm /stripchart /computer:time.windows.com /samples:5. Record the offset, stratum and last successful sync so you know whether the fix worked. - Confirm exactly one time daemon is running
Running chronyd and ntpd simultaneously causes port conflicts on UDP 123. Use systemctl list-units --type=service | grep -E 'ntp|chrony|systemd-timesyncd' and disable the ones you are not using. On Windows verify Get-Service w32time reports Running and StartType Automatic. - Test reachability to your NTP servers on UDP 123
ICMP ping proves nothing about NTP. Use ntpdate -q pool.ntp.org or chronyd -Q 'server pool.ntp.org iburst' from Linux, and w32tm /stripchart /computer:<server> from Windows. If every server times out, open UDP 123 outbound in the host, network and cloud security group. - Correct the configured servers and iburst behaviour
Edit /etc/chrony/chrony.conf or /etc/ntp.conf and use a diverse source set, for example 2.pool.ntp.org plus a regional pool, each with the iburst option so initial sync completes in seconds rather than minutes. On Windows domain members should sync from the PDC emulator, and only the PDC should point outward. - Force a one-shot step when the offset is huge
If offset exceeds a few hundred seconds, the daemon will not step automatically. Stop the service, run chronyd -q or ntpd -gq once to step the clock, then start the service again. On Windows use w32tm /resync /force after w32tm /config /update. - Disable competing time sources in virtual machines
In VMware, uncheck 'Synchronize guest time with host' in VM options and disable periodic sync via vmware-toolbox-cmd. For Hyper-V Linux guests, remove the 'Time Synchronization' integration service or blacklist the hv_utils time source so NTP is the sole discipline. - Restart, wait, and verify convergence
After changes, restart the service and wait at least two poll intervals (roughly 128 seconds with iburst). Re-run chronyc tracking or w32tm /query /status. You want stratum below 16, a chosen peer marked with '*', and an offset under 100 ms for general use or under 10 ms for authentication-critical workloads. - Set drift monitoring so this does not recur silently
Export the offset metric to your monitoring system, for example node_exporter's time collector or Windows Perfmon 'Windows Time Service' counters. Alert when offset exceeds one second or when the reference ID falls back to LOCAL, so drift is caught before it triggers Kerberos failures.
Common NTP symptoms mapped to likely cause and first action
| Symptom | Likely cause | First action |
|---|---|---|
| All peers show stratum 16, reach 0 | UDP 123 blocked outbound | Test with w32tm /stripchart or chronyd -Q, open firewall |
| Service exits with 'offset too large' | Initial drift over panic threshold | Run ntpd -gq or chronyd -q once to step, then start service |
| Offset oscillates by seconds every minute | VM host time sync fighting NTP | Disable guest-host time sync in VMware or Hyper-V |
| Kerberos clock skew on domain members | PDC emulator itself out of sync | Fix external sync on the PDC first, members follow |
| Windows shows 'Local CMOS Clock' source | w32time in NoSync mode | w32tm /config /syncfromflags:manual /manualpeerlist plus /update |
| chronyc sources shows '?' for all | DNS resolution failing for pool | Resolve pool.ntp.org, or use IP addresses temporarily |
Prevention
- Point every server at the same authoritative source hierarchy, typically the domain PDC emulator or a dedicated internal stratum-2 pair
- Allow UDP 123 outbound only from designated time servers, not from every workstation
- Keep hardware clocks reasonably close to real time with a working CMOS battery to avoid panic-threshold exits
- Alert on stratum 16, missing peer selection and offset over one second in your monitoring stack
FAQ
Why does ntpq -p show peers but none is selected with an asterisk?
The daemon has candidates but none passes the selection algorithm. Usually the offsets disagree by more than the tolerance, or every peer is stratum 16 because they themselves are unsynchronized. Add more diverse servers, wait several polling cycles, and check that your local clock is not so far off that all peers are rejected as falsetickers.
Is chrony better than ntpd for my servers?
Chrony handles intermittent connectivity, virtual machines and large initial offsets more gracefully, which is why most current Linux distributions ship it by default. Classic ntpd remains fine on always-on physical hosts with stable network paths. Pick one, disable the other, and standardize across the fleet to keep troubleshooting predictable.
How accurate does my clock actually need to be?
Active Directory and Kerberos tolerate five minutes of skew by default, so under one second is comfortable. Log correlation and SIEM analysis benefit from sub-100 ms accuracy. Financial trading, MiFID II reporting and PTP-grade telemetry demand microseconds, which requires PTP or GPS-disciplined hardware rather than plain NTP over the internet.
Contact our network team to review your NTP architecture and monitoring setup.