NTP Problem - 0x800705B4 - funktioniert auf keinem Server
Hallo zusammen,
wir haben vor Kurzem einen neuen Kunden übernommen und festgestellt, dass NTP überhaupt nicht funktioniert.
Da wir zunächst keinen Zugriff auf die bestehende Firewall hatten, haben wir das Thema erstmal hintenangestellt. Inzwischen wurde die Firewall durch eine eigene ersetzt – dennoch funktioniert NTP weiterhin nicht.
Woran es liegt, ist unklar. Die neue Firewall blockiert laut Logs nichts – sämtliche Verbindungen werden laut LOGS korrekt durchgelassen.
Folgendes wurde bereits getestet:
Genauere Informationen:
Ich freue mich über jede Unterstützung.
wir haben vor Kurzem einen neuen Kunden übernommen und festgestellt, dass NTP überhaupt nicht funktioniert.
Da wir zunächst keinen Zugriff auf die bestehende Firewall hatten, haben wir das Thema erstmal hintenangestellt. Inzwischen wurde die Firewall durch eine eigene ersetzt – dennoch funktioniert NTP weiterhin nicht.
Woran es liegt, ist unklar. Die neue Firewall blockiert laut Logs nichts – sämtliche Verbindungen werden laut LOGS korrekt durchgelassen.
Folgendes wurde bereits getestet:
- Lokale Windows-Firewall komplett deaktiviert
- UDP-Port 123 (NTP) explizit in der lokalen Firewall freigegeben
- Testweise eine Any-Regel für die betroffenen Hosts auf der Hardware-Firewall aktiviert
- NTP-Dienst registriert, deregistriert, Registry-Werte angepasst, verschiedene Zeitserver (Cloudflare, AWS etc.) ausprobiert
- NTP-Dienst gestoppt, neugestartet und erneut getestet
Genauere Informationen:
- Abbildungen sind von dem Haupt AD
Ich freue mich über jede Unterstützung.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672688
Url: https://administrator.de/forum/ntp-problem-0x800705b4-funktioniert-auf-keinem-server-672688.html
Ausgedruckt am: 21.05.2025 um 06:05 Uhr
20 Kommentare
Neuester Kommentar
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Hallo,
Die VMs laufen in VMWare ESXi.
Sollte ich noch etwas in VMWare einstellen? vielen Dank!
Die VMs laufen in VMWare ESXi.
Sollte ich noch etwas in VMWare einstellen? vielen Dank!
Zitat von @wollekuj:
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Hallo,
laufen der/die Server direkt auf Blech oder unter einem Hypervisor virtuell? Falls Hyper-V verwendet wird dann die Einstellungen an der Vm im Client zur Zeitsynchronisation mit dem Host abschalten. Ansonsten wären mehr Infos zur Situation nötig
Ich habe jetzt versucht, die Zeitsynchronisation in VMWare auszuschalten, aber leider hilft das nicht... immer noch erfolglos.
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Zitat von @tikayevent:
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Schau mal in den Gruppenrichtlinien. Wir hatten den Fall, dass wir eine Richtlinie hatten, die dafür gesorgt hat, dass NTP im Kreis gelaufen ist.
In der Default Domain Controller Policy gibst du deinen bevorzugen externen NTP-Server an und in der Default Domain Policy einen Round Robin DNS-Eintrag der die DC beinhaltet, mit dem sich die Clients synchronisieren sollen.
Alternativ, wenn du HP-Switches hast, gibt es eine Funktion, die mit DoS Protection oder ähnlichem beschriftet ist, die dafür sorgt, dass Dienste, deren Source- und Destination-Port identisch sind (was bei NTP gegeben ist) einfach nicht mehr funktionieren.
Hallo,
danke für deine Hilfe.
In der Domäne ist, denke ich, eher weniger etwas. Ich habe hier einen Test-Linux-Host, der nicht in der Domäne ist, und auch hier funktioniert es leider nicht.
Ich vermute, es muss irgendetwas am Switch oder Ähnlichem liegen – irgendeine bestimmte Funktion, denke ich, da kein Host per NTP nach außen kommt.
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Kann die eigesetzte Firewall denn evtl auch ntp?
Vlt an einem Client mal
w32tm /config /manualpeerlist:"firewallip",0x8 /syncfromflags:MANUAL
net stop "windows time"
net start "windows time"
w32tm /resync
Vlt an einem Client mal
w32tm /config /manualpeerlist:"firewallip",0x8 /syncfromflags:MANUAL
net stop "windows time"
net start "windows time"
w32tm /resync
Zitat von @DivideByZero:
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Moin,
Du testet ja immer nach außen. Nur vom DC aus? Wie sieht es denn an einem Client aus, kommt der raus (dann wäre Firewall ja nicht das Problem)?
Was passiert denn beim Setzen einer neuen Source? Der Fehler oben sagt ja nichts anderes, als dass lokal keine Source erreichbar ist (Windows Time Sync error: 0x800705B4).
Teste mal bei einem Client mit einer NTP-Clientsoftware und so etwas wie ptbtime1.ptb.de als Server: www.meinberg.de/german/sw/ntp.htm
Gruß
DivideByZero
P.S.: Sehe gerade Deinen Post. Dann teste doch mal direkt die Ports und hänge Dich ohne Switch direkt an die Firewall, ggf. auch mal daran vorbei, um das blockierende Gerät zu finden.
Hallo,
ich habe gerade auch aus einem Linux-Host getestet, und es funktioniert ebenfalls nicht. Auch von einem Windows-Client aus habe ich es versucht, ohne Erfolg. Das Problem tritt nicht nur im DC auf, sondern überall.
Das Tool habe ich ebenfalls heruntergeladen und getestet, jedoch funktioniert es auch darüber nicht.
Das Setzen einer Source bzw. mehrerer Sources habe ich ebenfalls schon ausprobiert.
Viele Grüße
Moin,
Schmeiß
a) WireShark an und schau was passiert
b) das Logging in der vorgelagerten Firewall (welche eigentlich? pfSense? Sophos? Sonicwall?…) an und schaue, wo die Pakete kleben bleiben.
BTW: unsere DCs fragen die Zeit an unserer Firewall an. Diese leitet die Anfragen dann als Stellvertreter an extern weiter. Früher war unsere Sophos selbst in Richtung WAN als NTP Client aktiv und in Richtung LAN als NTP-Server. Somit musste man kein (ausgehendes) Loch in die Firewall bohren
Schmeiß
a) WireShark an und schau was passiert
b) das Logging in der vorgelagerten Firewall (welche eigentlich? pfSense? Sophos? Sonicwall?…) an und schaue, wo die Pakete kleben bleiben.
BTW: unsere DCs fragen die Zeit an unserer Firewall an. Diese leitet die Anfragen dann als Stellvertreter an extern weiter. Früher war unsere Sophos selbst in Richtung WAN als NTP Client aktiv und in Richtung LAN als NTP-Server. Somit musste man kein (ausgehendes) Loch in die Firewall bohren
1
Moin,
In so einem Fall wirft man erstmal ei en sniffer wie wireshark o.ä. an und schaut, ob und welche Pakete wohin gehen.
lks
In so einem Fall wirft man erstmal ei en sniffer wie wireshark o.ä. an und schaut, ob und welche Pakete wohin gehen.
lks
1
Nabend.
Was wird denn für eine Firewall eingesetzt? Kann diese eventuell auch einen Paket-Mitschnitt anfertigen?
Falls ja, dann dort mal auf dem Port UDP 123 "lauschen".
Falls nein, dann, wie schon mehrfach vorgeschlagen, mit einem Wireshark dasselbe auf einem betroffenen Client / Server schauen.
Für mich riecht das auch nach fehlender Firewall ins WAN für NTP.
Ich würde mich an den Vorschlag von @em-pie dranhängen und NTP durch die Firewall bereitstellen für die DC und diese geben die Zeit wiederum an die übrigen Domain-Member weiter.
Gruß
Marc
Was wird denn für eine Firewall eingesetzt? Kann diese eventuell auch einen Paket-Mitschnitt anfertigen?
Falls ja, dann dort mal auf dem Port UDP 123 "lauschen".
Falls nein, dann, wie schon mehrfach vorgeschlagen, mit einem Wireshark dasselbe auf einem betroffenen Client / Server schauen.
Für mich riecht das auch nach fehlender Firewall ins WAN für NTP.
Ich würde mich an den Vorschlag von @em-pie dranhängen und NTP durch die Firewall bereitstellen für die DC und diese geben die Zeit wiederum an die übrigen Domain-Member weiter.
Gruß
Marc
Moin @b1nzy1,
zu dem Bild was du im Einganspost mit angehängt hast.
Dieses Problem zumindest ...
... hängt ganz sicher nicht an deiner Umgebung, sondern ist eher der verwendeten Zeitquelle geschuldet. 😉
Ist ja nicht so, dass wir in Deutschland nicht auch sehr zuverlässige ...
https://www.ptb.de/cms/ptb/fachabteilungen/abt9/gruppe-95/ref-952/zeitsy ...
... Zeitquellen hätten. 😁
Für DC's:
Und falls du einen Domain-Member direkt synchronisieren möchtest.
Wir verwenden bei unds und unseren Kunden schon seit Jahren die Zeitserver der PTB und hatten damit noch nie irgendwelche Probleme.
Was spuckt den auf deinem DC das hier ...
... aus?
Gruss Alex
zu dem Bild was du im Einganspost mit angehängt hast.
Dieses Problem zumindest ...
... hängt ganz sicher nicht an deiner Umgebung, sondern ist eher der verwendeten Zeitquelle geschuldet. 😉
Ist ja nicht so, dass wir in Deutschland nicht auch sehr zuverlässige ...
https://www.ptb.de/cms/ptb/fachabteilungen/abt9/gruppe-95/ref-952/zeitsy ...
... Zeitquellen hätten. 😁
Für DC's:
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de ptbtime4.ptb.de" /syncfromflags:manual /reliable:yes /update Und falls du einen Domain-Member direkt synchronisieren möchtest.
w32tm /config /manualpeerlist:"ptbtime1.ptb.de ptbtime2.ptb.de ptbtime3.ptb.de ptbtime4.ptb.de" /syncfromflags:manual /reliable:no /update Wir verwenden bei unds und unseren Kunden schon seit Jahren die Zeitserver der PTB und hatten damit noch nie irgendwelche Probleme.
Was spuckt den auf deinem DC das hier ...
w32tm /query /source... aus?
Gruss Alex
Hi,
stimmt denn das Routing überhaupt? Sprich, geht ein ping ptbtime1.ptb.de?
EDIT: Vergiss den ping, die Server antworten nicht ....
Und vor allem, was siehst du in der Firewall?
Stell die Regeln auf Logging und gucke was passiert, wenn du dann nichts siehst, kommt auch gar nicht an der Firewall an.
Nur weil die keine Block siehst, heißt das nicht das auch ein Paket durchgeht.
Zusätzlich mit den obigen Tipps, solltest du dann der Sache nahe kommen
Viele Grüße
Deepsys
stimmt denn das Routing überhaupt? Sprich, geht ein ping ptbtime1.ptb.de?
EDIT: Vergiss den ping, die Server antworten nicht ....
Und vor allem, was siehst du in der Firewall?
Stell die Regeln auf Logging und gucke was passiert, wenn du dann nichts siehst, kommt auch gar nicht an der Firewall an.
Nur weil die keine Block siehst, heißt das nicht das auch ein Paket durchgeht.
Zusätzlich mit den obigen Tipps, solltest du dann der Sache nahe kommen
Viele Grüße
Deepsys
Ziemlich sinnfrei auch US Timeserver zu benutzen. Wenn, sollten es ja immer lokale sein, sprich in D liegen oder zu mindestens in der EU um das Delay so gering wie möglich zu halten. 
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
oder den generell üblichen Pool der deutschen Zeitserver de.pool.ntp.org.
https://www.ntppool.org/zone/de
Letzterer ist auch pingbar
user@server: ping -c3 de.pool.ntp.org
PING de.pool.ntp.org (94.130.23.46): 56 data bytes
64 bytes from 94.130.23.46: icmp_seq=0 ttl=58 time=21.551 ms
64 bytes from 94.130.23.46: icmp_seq=1 ttl=58 time=28.584 ms
64 bytes from 94.130.23.46: icmp_seq=2 ttl=58 time=27.386 ms
Den Rest checkt man in der Tat mit dem Wireshark indem man z.B. den lokalen Winblows NTP Client auf den o.a. Pool einstellt und prüft ob der aus dem lokalen Netz synchronisiert.
https://www.rz.uni-osnabrueck.de/Dienste/NTP/win10.htm
Unter Linux geht das am besten mit timedatectl timesync-status
Ein Time Server Monitor Tool zeigt unter Winblows zudem die NTP Zugriffe auch grafisch zur Überwachung auf:
https://www.meinberg.de/german/sw/ntp-server-monitor.htm#download
Solche NTP Banalitäten sollte man als Administrator eigentlich auch selber wissen?!
https://www.heise.de/ratgeber/oeffentliche-Zeitquellen-322978.html
oder den generell üblichen Pool der deutschen Zeitserver de.pool.ntp.org.
https://www.ntppool.org/zone/de
Letzterer ist auch pingbar
user@server: ping -c3 de.pool.ntp.org
PING de.pool.ntp.org (94.130.23.46): 56 data bytes
64 bytes from 94.130.23.46: icmp_seq=0 ttl=58 time=21.551 ms
64 bytes from 94.130.23.46: icmp_seq=1 ttl=58 time=28.584 ms
64 bytes from 94.130.23.46: icmp_seq=2 ttl=58 time=27.386 ms
Den Rest checkt man in der Tat mit dem Wireshark indem man z.B. den lokalen Winblows NTP Client auf den o.a. Pool einstellt und prüft ob der aus dem lokalen Netz synchronisiert.
https://www.rz.uni-osnabrueck.de/Dienste/NTP/win10.htm
Unter Linux geht das am besten mit timedatectl timesync-status
Ein Time Server Monitor Tool zeigt unter Winblows zudem die NTP Zugriffe auch grafisch zur Überwachung auf:
https://www.meinberg.de/german/sw/ntp-server-monitor.htm#download
Solche NTP Banalitäten sollte man als Administrator eigentlich auch selber wissen?!
Powershell
und DOS
dann siehst du A ob der Port durchgereicht wird und B ggf. wo im routing es hängen bleibt.
ich persönlich verwende NTP so das einer der DCs die "Master" Rolle bekommt. Bedeutet der Synct vom NTP Server.
Und alle anderen DCs vom "Master" DC. Und Clients und Server etc.... syncen alle von den DCs ihre Zeit.
Muss man halt im Kopf haben wenn man DCs austauscht das da der Chef NTP Server ist aber da das auch nur alle paaaaar Jahre ist hält sich der Aufwand in grenzen...
test-netconnection ntp.servername.de -Port 123und DOS
tracert ntp.servername.de dann siehst du A ob der Port durchgereicht wird und B ggf. wo im routing es hängen bleibt.
ich persönlich verwende NTP so das einer der DCs die "Master" Rolle bekommt. Bedeutet der Synct vom NTP Server.
Und alle anderen DCs vom "Master" DC. Und Clients und Server etc.... syncen alle von den DCs ihre Zeit.
Muss man halt im Kopf haben wenn man DCs austauscht
das da der Chef NTP Server ist aber da das auch nur alle paaaaar Jahre ist hält sich der Aufwand in grenzen...dann siehst du A ob der Port durchgereicht wird
Zu mindestens mit dem Traceroute Kommando nur bedingt. Das Winblows Traceroute kann keinen UDP basierten Traceroute sondern einzig und allein nur über ICMP Echo. Ist das blockiert in der FW des TOs scheitert der Traceroute obwohl dennoch der NTP UDP oder TCP Port aktiv sein kann. NTP benutzt wie DNS beide Optionen, also sowohl UDP 123 als auch TCP 123. Beide Ports sollten in einer FW geöffnet sein für NTP.Zur Not kann der TO ja auch immer einen 10€ Raspberry Pi Zero aus der Bastelschublade nehmen und für ein paar Euro eine GPS Maus per USB anstöpseln. Dann bekommt er für unter 20€ einen hochgenauen NTP Server mit Atomuhr Zeit im lokalen Netz und es kann ihm dann völlig Wumpe sein was auf der Firewall konfiguriert ist oder was nicht!
Zitat von @b1nzy1:
Ich vermute, es muss irgendetwas am Switch oder Ähnlichem liegen – irgendeine bestimmte Funktion, denke ich, da kein Host per NTP nach außen kommt.
Ich vermute, es muss irgendetwas am Switch oder Ähnlichem liegen – irgendeine bestimmte Funktion, denke ich, da kein Host per NTP nach außen kommt.
Bist du dem mal nachgegangen? Theoretisch könnten ACL's auf dem Switch natürlich auch eine Verbindung verhindern. Wenn die Anfrage nicht bis zur Firewall durchkommt und es am Client auch nicht liegt, wäre das ja recht naheliegend wenn auch ungewöhnlich.
Ansonsten: DNS-Auflösung passt? Nicht dass da ne Blockliste läuft oder so.
Und wie bekommt eure Firewall eine Uhrzeit? Hast mal geschaut ob dort NTP funktioniert?
Wireshark wurde ja schon häufig genug erwähnt :D
Zitat von @aqui:
dann siehst du A ob der Port durchgereicht wird
Zu mindestens mit dem Traceroute Kommando nur bedingt. Das Winblows Traceroute kann keinen UDP basierten Traceroute sondern einzig und allein nur über ICMP Echo. Ist das blockiert in der FW des TOs scheitert der Traceroute obwohl dennoch der NTP UDP oder TCP Port aktiv sein kann.ja aber wenn der an der firewall scheitert, dann ist der letzte eintrag die firewall, und somit weiss man wo man suchen muss. klar das klappt nicht immer aber so zu 95% kriegt man intern schon raus wo es kleben bleibt
vor allem falls es ein Routing Problem in irgendeiner form ist.
Wenn es das denn nun war als Lösung bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Hallo zusammen,
wir haben das Problem gelöst, indem wir für die Firewall NTP freigeschaltet haben und die Firewall als NTP-Server verwenden.
Alles funktioniert nun wie gewünscht. Ich danke für jede Unterstützung!
wir haben das Problem gelöst, indem wir für die Firewall NTP freigeschaltet haben und die Firewall als NTP-Server verwenden.
Alles funktioniert nun wie gewünscht. Ich danke für jede Unterstützung!
