NTP-Probleme beheben Sie, indem Sie zuerst den Dienststatus (ntpd, chronyd oder w32time) prüfen, dann die Erreichbarkeit der konfigurierten Zeitserver auf UDP-Port 123 testen und zuletzt die Konfigurationsdatei sowie den Offset kontrollieren. Danach erzwingen Sie eine manuelle Resynchronisation und überwachen die Drift.
Symptome
- Server-Logs zeigen inkonsistente oder rückwärts laufende Zeitstempel zwischen Hosts.
- Kerberos- oder Active-Directory-Anmeldungen scheitern mit Zeitversatz-Fehlern (KRB_AP_ERR_SKEW).
- ntpq -p oder chronyc tracking meldet „no reachable servers
- unsynchronised
- TLS-Zertifikate werden trotz Gültigkeit als abgelaufen oder noch nicht gültig zurückgewiesen.
- Der Offset zum Zeitserver überschreitet dauerhaft mehrere Sekunden trotz aktivem Dienst.
Häufige Ursachen
UDP-Port 123 durch Firewall blockiert
Perimeter- oder Host-Firewalls lassen ausgehende NTP-Pakete nicht passieren. Betroffen sind vor allem gehärtete Server oder Segmente hinter NAT ohne explizite Regel für UDP/123.
Falsch konfigurierte oder nicht erreichbare Zeitquelle
In ntp.conf, chrony.conf oder der w32time-Registry ist ein Server eingetragen, der nicht mehr existiert, DNS nicht auflöst oder wegen Stratum-16-Status keine Zeit liefert.
Dienstkonflikt zwischen ntpd, chronyd und systemd-timesyncd
Wenn zwei Zeitdienste gleichzeitig aktiv sind, überschreiben sie sich gegenseitig. Häufig nach Distributions-Upgrades, wenn timesyncd parallel zum installierten chronyd läuft.
Große initiale Zeitdifferenz (Panic Threshold)
Weicht die Systemzeit um mehr als 1000 Sekunden ab, verweigert ntpd standardmäßig die Synchronisation und beendet sich. Chrony verhält sich ohne makestep-Direktive ähnlich zurückhaltend.
Virtualisierungs-Drift im Gast-BS
VMs erben Taktabweichungen vom Host, wenn Paravirtualisierungs-Clocks (kvm-clock, VMware Tools Time Sync) und Gast-NTP gleichzeitig aktiv sind. Das Ergebnis: konkurrierende Zeitquellen und wandernder Offset.
Schritt-für-Schritt-Lösung
- Aktuelle Zeit, Offset und Synchronisationsquelle auslesen
Führen Sie unter Linux `timedatectl` sowie `chronyc tracking` bzw. `ntpq -pn` aus. Unter Windows liefert `w32tm /query /status` und `w32tm /query /peers` Auskunft. Notieren Sie sich Stratum, Offset und den Namen der aktiven Referenzquelle für den Vergleich nach dem Fix. - Läuft überhaupt der richtige Zeitdienst?
Prüfen Sie mit `systemctl status chronyd ntp systemd-timesyncd`, welcher Dienst aktiv ist. Nur einer darf laufen. Deaktivieren Sie die übrigen mit `systemctl disable --now <dienst>`. Unter Windows: `Get-Service w32time`; ist der Dienst gestoppt, mit `net start w32time` starten. - Erreichbarkeit der Zeitserver testen
Testen Sie UDP/123 gezielt mit `ntpdate -q pool.ntp.org` oder `chronyd -Q 'server pool.ntp.org iburst'`. Antwortet der Server nicht, prüfen Sie Firewall-Regeln, NAT und ob DNS die Poolnamen korrekt auflöst. In segmentierten Netzen benötigen Sie oft eine explizite ausgehende Regel. - Konfigurationsdatei überprüfen und anpassen
Öffnen Sie `/etc/chrony/chrony.conf` bzw. `/etc/ntp.conf` und stellen Sie sicher, dass mindestens drei bis vier `pool`- oder `server`-Einträge mit `iburst` vorhanden sind. In Domänen sollten interne Domänencontroller als Quelle dienen, nicht öffentliche Pools. Auf Windows setzen Sie die Peerliste mit `w32tm /config /manualpeerlist:"dc01.example.local" /syncfromflags:manual /update`. - Große Zeitdifferenz einmalig überbrücken
Wenn der Offset im Sekunden- oder Minutenbereich liegt, stoppen Sie den Dienst und setzen die Zeit hart: `chronyd -q 'server pool.ntp.org iburst'` oder unter Windows `w32tm /resync /force`. Danach den Dienst wieder starten. Bei chrony hilft die Direktive `makestep 1.0 3`, um beim Start automatisch grobe Sprünge zuzulassen. - Virtualisierungs-Zeitquellen entkoppeln
In VMs deaktivieren Sie entweder die Host-Zeitsynchronisation (VMware Tools: `tools.syncTime = FALSE`; Hyper-V: Integrationsdienst „Zeitsynchronisierung - Ergebnis über mehrere Minuten verifizieren
Warten Sie fünf bis zehn Minuten und prüfen Sie erneut `chronyc tracking` bzw. `w32tm /query /status`. Der Offset sollte im Millisekundenbereich stabil bleiben, Stratum unter 16 liegen und die Referenzquelle konstant sein. Prüfen Sie parallel `/var/log/chrony/` oder das Windows-Event-Log auf verbleibende Warnungen.
Typische NTP-Fehlermeldungen und passende Gegenmaßnahmen
| Meldung / Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| no reachable servers | UDP/123 blockiert oder falscher Servername | Firewall-Regel prüfen, DNS-Auflösung testen |
| unsynchronised, stratum 16 | Dienst läuft, hat aber keine gültige Quelle | Erreichbarkeit mit ntpdate -q oder chronyd -Q prüfen |
| Offset > 1000 s, ntpd beendet sich | Panic Threshold überschritten | Zeit einmalig mit chronyd -q oder w32tm /resync setzen |
| KRB_AP_ERR_SKEW bei AD-Login | Client weicht > 5 min vom DC ab | Client gegen den PDC-Emulator synchronisieren |
| Offset schwankt periodisch | Konkurrierende Host-Zeitquelle in VM | Host-Time-Sync im Hypervisor deaktivieren |
| Access denied bei w32tm | Fehlende Adminrechte oder Gruppenrichtlinie | Konsole als Administrator öffnen, GPO prüfen |
So beugen Sie vor
- Mindestens drei geografisch verteilte Zeitquellen konfigurieren, damit einzelne Ausfälle keine Sync-Lücke erzeugen.
- Interne Stratum-2-Server für alle Clients bereitstellen und nur diese durch die Firewall zu öffentlichen Pools lassen.
- Monitoring auf Offset und Stratum einrichten, zum Beispiel per Prometheus node_exporter oder SNMP-Abfrage.
- Nach OS-Upgrades prüfen, ob nicht ungewollt ein zweiter Zeitdienst aktiviert wurde.
Häufige Fragen
Welchen Offset sollte NTP im Normalbetrieb nicht überschreiten?
Für die meisten Anwendungen genügt ein Offset unter 100 Millisekunden. Kerberos und Active Directory tolerieren standardmäßig fünf Minuten, was in der Praxis viel zu großzügig ist. Für Log-Korrelation, verteilte Datenbanken und Zertifikatsprüfungen sollten Sie unter 50 ms bleiben und den Wert aktiv überwachen.
Warum synchronisiert Windows nach dem Domänenbeitritt nicht mehr mit externen Zeitservern?
Nach dem Domänenbeitritt stellt der Zeitdienst automatisch auf den Domänen-Hierarchie-Modus um. Clients synchronisieren dann gegen den authentifizierenden Domänencontroller, dieser wiederum gegen den PDC-Emulator. Nur der PDC-Emulator sollte extern konfiguriert werden, sonst entsteht eine inkonsistente Zeit in der Domäne.
Ist chrony besser geeignet als klassisches ntpd?
Chrony gilt in modernen Linux-Distributionen als Standard, weil es mit unregelmäßigen Netzwerkverbindungen, virtuellen Maschinen und Laptops besser umgeht und schneller konvergiert. Klassisches ntpd bleibt sinnvoll, wenn Sie NTPv4-Broadcast, komplexe Autokey-Konfigurationen oder Referenz-Clock-Hardware betreiben.
Lassen Sie unser Team Ihre Zeitinfrastruktur prüfen und eine stabile NTP-Hierarchie einrichten.