NTP-Probleme lösen Sie in drei Schritten: Zuerst prüfen, ob der Zeitdienst (ntpd, chrony oder w32time) läuft, dann Erreichbarkeit der konfigurierten Server über UDP 123 testen und zuletzt Konfiguration sowie Offset validieren. Falsche Server, blockierte Firewalls oder ein gestoppter Dienst sind die häufigsten Ursachen.
Symptome
- Zeitstempel in Logs weichen um Sekunden oder Minuten von der realen Uhrzeit ab
- Kerberos-Anmeldungen schlagen mit Fehler „Clock skew too great" fehl
- ntpq -p zeigt keinen Peer mit Stern (*) oder Reach 0
- w32tm /query /status meldet „Der Dienst hat noch nicht synchronisiert"
- TLS-Zertifikate erscheinen als „noch nicht gültig" oder abgelaufen
Häufige Ursachen
Falsch konfigurierte Zeitquellen
Der Server verweist auf nicht erreichbare Pools, interne DNS-Namen ohne Auflösung oder auf sich selbst. Ohne gültige Quelle bleibt der Offset unkorrigiert.
Blockiertes UDP auf Port 123
Firewalls, Security-Groups oder NAT-Regeln verwerfen NTP-Pakete. Die Antwortpakete des Zeitservers erreichen den Client nicht, obwohl die Anfrage rausgeht.
Dienst gestoppt oder deaktiviert
Nach Updates oder manuellen Eingriffen ist ntpd, chronyd oder der Windows-Zeitdienst w32time nicht mehr aktiv. Ohne laufenden Daemon findet keine Korrektur statt.
Konkurrierende Zeitquellen
Virtualisierungsplattformen wie VMware Tools oder Hyper-V-Zeitsynchronisation überschreiben die Uhrzeit parallel zum NTP-Dienst. Das erzeugt Sprünge und ständige Nachkorrektur.
Hoher Drift oder defekte RTC
Eine alternde CMOS-Batterie oder eine schlecht laufende Hardware-Uhr erzeugt einen Drift, den NTP nicht mehr sanft ausgleichen kann und ablehnt.
Schritt-für-Schritt-Lösung
- Aktuellen Zeitversatz und Sync-Status ermitteln
Unter Linux liefert `timedatectl status` einen schnellen Überblick, ob der Systemtakt als synchronisiert gilt. Für Details nutzen Sie `chronyc tracking` oder `ntpq -pn`. Unter Windows zeigt `w32tm /query /status` und `w32tm /query /peers` Quelle, Offset und Stratum. Notieren Sie den Offset in Sekunden. - Zeitdienst prüfen und gezielt neu starten
Kontrollieren Sie den Daemon-Zustand. Linux: `systemctl status chronyd` oder `systemctl status ntp`. Läuft er nicht, starten Sie ihn mit `systemctl restart chronyd`. Unter Windows prüfen Sie `Get-Service w32time` und starten mit `net stop w32time && net start w32time`. Vermeiden Sie parallel laufende Zeitdienste auf demselben Host. - Konfigurierte NTP-Server validieren
Öffnen Sie `/etc/chrony/chrony.conf` bzw. `/etc/ntp.conf` und prüfen Sie die `server`- oder `pool`-Zeilen. Für Deutschland eignen sich `de.pool.ntp.org` oder `ptbtime1.ptb.de`. Auf Windows-Domänencontrollern setzen Sie externe Quellen per `w32tm /config /manualpeerlist:"ptbtime1.ptb.de" /syncfromflags:manual /update`. - Netzwerk-Erreichbarkeit auf UDP 123 testen
NTP nutzt UDP-Port 123. Testen Sie mit `ntpdate -q pool.ntp.org` oder `chronyc sources -v`, ob Antworten eintreffen. Prüfen Sie Host-Firewall (`ufw`, `firewalld`, Defender), Netzwerk-ACLs und in Cloud-Umgebungen die Security-Group. Ohne beidseitige UDP-123-Freigabe bleibt jeder weitere Fix wirkungslos. - Konkurrierende Zeitquellen deaktivieren
Auf virtuellen Maschinen kollidiert die Host-Zeitsynchronisation häufig mit NTP. Deaktivieren Sie in VMware Tools die Option „Time synchronization" oder unter Hyper-V den Integrationsdienst „Zeitsynchronisation". Auf Domänen-Mitgliedern soll nur der PDC-Emulator externe Zeit beziehen, andere Server nehmen Domänenzeit. - Drift, Stratum und Offset final prüfen
Nach den Änderungen warten Sie einige Minuten und prüfen erneut mit `chronyc tracking` bzw. `w32tm /query /status`. Ein Peer sollte in `ntpq -pn` mit `*` markiert sein, der Offset im Millisekundenbereich liegen und das Stratum niedriger als 16 sein. Persistieren Sie die Konfiguration und aktivieren Sie den Dienst beim Boot.
Typische Fehlerbilder, Ursache und schneller Fix
| Symptom | Wahrscheinliche Ursache | Behebung |
|---|---|---|
| ntpq -p ohne Stern-Peer | Keine erreichbare Quelle | Server-Zeilen prüfen, UDP 123 freigeben |
| Reach = 0 | Firewall verwirft Pakete | ACL/Firewall auf ein- und ausgehendes UDP 123 prüfen |
| Kerberos: Clock skew too great | Offset > 5 Minuten | Zeit manuell setzen, dann Dienst neu synchronisieren |
| w32time synchronisiert nie | Falscher Announce-Flag | w32tm /config mit /reliable:yes auf PDC setzen |
| Sprünge alle paar Minuten | Doppelte Zeitquelle (VM-Tools + NTP) | Host-Zeitsync im Hypervisor deaktivieren |
| Stratum 16 dauerhaft | Dienst gestartet, aber Quelle unerreichbar | DNS-Auflösung und Server-Antwort testen |
So beugen Sie vor
- Mindestens drei diverse Zeitquellen konfigurieren, damit ein Ausfall abgefangen wird
- In Domänen ausschließlich den PDC-Emulator gegen externe NTP-Server synchronisieren
- Monitoring auf Offset > 1 Sekunde und Stratum 16 einrichten (z. B. Prometheus, Zabbix)
- UDP 123 in Firewall-Regeln und Security-Groups explizit dokumentieren und freigeben
Häufige Fragen
Wie groß darf der Offset maximal sein, bevor NTP nicht mehr korrigiert?
Der ntpd verweigert per Default Sprünge über 1000 Sekunden und beendet sich. chrony ist toleranter, springt aber nur, wenn `makestep` konfiguriert ist. In der Praxis sollten Sie bei Offsets über wenigen Minuten die Zeit einmalig manuell setzen (`chronyc makestep` oder `w32tm /resync /force`) und danach den Normalbetrieb starten.
Sollte ich pool.ntp.org oder eigene Server verwenden?
Für einzelne Clients ist der öffentliche Pool ausreichend. Ab mehreren Dutzend Geräten empfiehlt sich ein interner Stratum-2-Server, der gegen `de.pool.ntp.org` oder die PTB in Braunschweig synchronisiert. Das reduziert Last auf öffentlichen Servern und macht Sie unabhängig von externer Erreichbarkeit.
Warum weicht die Zeit auf virtuellen Maschinen ständig ab?
Virtuelle Uhren driften stärker als physische, weil der Hypervisor CPU-Zeit dynamisch zuteilt. Wenn zusätzlich Hypervisor-Zeitsynchronisation und NTP parallel laufen, korrigieren beide gegeneinander. Deaktivieren Sie eine der beiden Quellen und lassen Sie im Gast ausschließlich chrony oder w32time laufen.