NTP-Synchronisierungsprobleme für Clients

yaldoo · 22. Januar 2026 – 15:05 Uhr

Guten Morgen,

Ich nutze Debian 13 mit der neuesten Version von Samba-AD.
Ich habe die Anweisungen befolgt https://samba.tranquil.it/doc/fr/samba_ ... ebian.html
Der Chrony-Dienst läuft, der Socket hat die korrekten Berechtigungen, aber mein Server reagiert nicht auf signierte Anfragen (Länge 120)

w32tm /stripchart /computer:172.16.2.1 /samples:1 /dataonly

Code: Alle auswählen

14:57:49.034807 IP (tos 0x0, ttl 128, id 62657, offset 0, flags [none], proto UDP (17), length 76)
    10.0.248.10.54507 > 172.16.2.1.123: NTPv1, Client, length 48
        Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3978079066.333766699 (2026-01-22T13:57:46Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3978079066.333766699 (2026-01-22T13:57:46Z)
14:57:49.034891 IP (tos 0x0, ttl 64, id 55417, offset 0, flags [DF], proto UDP (17), length 76)
    172.16.2.1.123 > 10.0.248.10.54507: NTPv1, Server, length 48
        Leap indicator:  (0), Stratum 3 (secondary reference), poll 0 (1s), precision -26
        Root Delay: 0.019027, Root dispersion: 0.000473, Reference-ID: 0x3ed281ab
          Reference Timestamp:  3978079058.980249532 (2026-01-22T13:57:38Z)
          Originator Timestamp: 3978079066.333766699 (2026-01-22T13:57:46Z)
          Receive Timestamp:    3978079069.034855657 (2026-01-22T13:57:49Z)
          Transmit Timestamp:   3978079069.034928405 (2026-01-22T13:57:49Z)
            Originator - Receive Timestamp:  +2.701088958
            Originator - Transmit Timestamp: +2.701161705

w32tm /resync /nowait

Code: Alle auswählen

15:01:52.210935 IP (tos 0x0, ttl 128, id 18487, offset 0, flags [none], proto UDP (17), length 148)
    10.0.248.10.123 > 172.16.2.1.123: NTPv3, Client, length 120
        Leap indicator:  (0), Stratum 1 (primary reference), poll 17 (131072s), precision -23
        Root Delay: 0.000000, Root dispersion: 10.000000, Reference-ID: LOCL
          Reference Timestamp:  3978079309.366612899 (2026-01-22T14:01:49Z)
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3978079309.507616199 (2026-01-22T14:01:49Z)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3978079309.507616199 (2026-01-22T14:01:49Z)
        (72 more bytes after the header)

Im ersten Fall erhalte ich eine Antwort, im zweiten jedoch nicht.
Ich habe alles versucht, aber nichts funktioniert. Hatten Sie schon einmal dieses Problem?

22. Januar 2026 – 16:45 Uhr

Hallo Julien,

Bezüglich der DC(s): Sagt Chrony, dass er mit MS-SNTP sehr zufrieden ist?

Code: Alle auswählen

# cat  daemon.log | grep MS-SNTP
Sep  4 19:18:52 dc-xxxxx chronyd[893]: MS-SNTP authentication enabled

und dass es kein

Code: Alle auswählen

CONFIG: MS-SNTP signd operations currently block ntpd degrading service to all clients.

Denis

yaldoo · 23. Januar 2026 - 09:27 Uhr

Vielen Dank für Ihre Antworten. Die Protokolle scheinen auf beiden Domänencontrollern in Ordnung zu sein

Code: Alle auswählen

# sudo journalctl -g "MS-SNTP"
Jan 23 08:45:13 ad-xxxxxx chronyd[801]: MS-SNTP authentication enabled

Ich habe allerdings keine Logdatei in /var/log/chrony

Ich habe versucht, ein Upgrade durchzuführen und das System neu zu starten... nichts hat funktioniert

Kann ich Ihrer Meinung nach einen NTP-Server per Gruppenrichtlinie (GPO) einbinden?

6. Februar 2026 – 9:36 Uhr

Hallo Julien,

Windows-Workstations arbeiten standardmäßig im NTDS5-NTP-Modus. Das bedeutet, sie verbinden sich über eine sichere Methode (SNTP) basierend auf dem Active Directory-Konto des Rechners mit Domänencontrollern für NTP.

Bei Bedarf können Sie ein Gruppenrichtlinienobjekt (GPO) implementieren, das auf andere NTP-Server verweist. In diesem Fall wird jedoch Standard-NTP anstelle von SNTP verwendet, was meines Erachtens nur dann ein Problem darstellt, wenn Sie ein Netzwerk mit besonders hohen Sicherheitsanforderungen benötigen.

Der NTDS5-NTP-Modus sollte aber ohnehin sofort funktionieren.

Viele Grüße,

Denis

Ploubi · 10. August 2026 – 17:30 Uhr

Guten Morgen,

Ich habe ein Problem mit den Uhren meiner Client-Workstations (Windows).
Die Serverkonfiguration entspricht der Dokumentation: https://samba.tranquil.it/doc/en/samba_ ...ebian.html
MS-SNTP scheint aktiv zu sein

urr-deb-smbad:/home/urrugne# systemctl status chrony
● chrony.service - chrony, ein NTP-Client/Server
Geladen: geladen (/lib/systemd/system/chrony.service; aktiviert; Standardeinstellung: aktiviert)
Aktiv: aktiv (läuft) seit Mo 2026-08-10 15:39:16 CEST; Vor 1 Stunde 44 Minuten
Dokumentation: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
Haupt-PID: 302393 (chronyd)
Aufgaben: 2 (Limit: 4562)
Speicher: 1,5 MB
CPU: 91 ms
CGroup: /system.slice/chrony.service
├─302393 /usr/sbin/chronyd -F 1
└─302394 /usr/sbin/chronyd -F 1 10.

Aug. 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: chronyd Version 4.3 wird gestartet (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
10. Aug. 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Frequenz -39,237 +/- 0,007 ppm aus /var/lib/chrony/chrony.drift gelesen
10. Aug. 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Verwende die richtige/UTC-Zeitzone, um Schaltsekundendaten zu erhalten
10. Aug. 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: MS-SNTP-Authentifizierung aktiviert
10. Aug. 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: seccomp-Filter (Stufe 1) geladen
10. Aug 15:39:16 urr-deb-smbad.ville-urrugne.fr systemd[1]: Started chrony.service - chrony, ein NTP-Client/Server.
10. Aug. 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Quelle 109.190.177.200 (2.debian.pool.ntp.org) ausgewählt.
10. Aug. 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Systemuhr-TAI-Offset auf 37 Sekunden gesetzt.
10. Aug. 15:40:27 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Quelle 217.154.21.219 (2.debian.pool.ntp.org) ausgewählt.
10. Aug. 15:44:46 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Ausgewählte Quelle 109.190.177.200 (2.debian.pool.ntp.org)

In den Windows-Einstellungen für Clients zur Zeiteinstellung ist festgelegt, dass einige Einstellungen „von meiner Organisation verwaltet“ werden
Die Schaltflächen „Jetzt synchronisieren“ und „Zeitserver bearbeiten“ sind aktiv, aber es schlägt fehl, wenn ich versuche, sie zu ändern (ich muss AD verlassen, um manuell neu zu synchronisieren und dann wieder beitreten).

"w32tm /query /status" gibt zurück, dass ich mich in Lokaler CMOS-Takt anstelle des Samba AD-Servers
"w32tm.exe /query /configuration" gibt zurück, dass ich mich tatsächlich in NT5DS
Mit "w32tm /monitor" scheint es jedoch in Ordnung zu sein, abgesehen von einer Warnung bezüglich Reverse-DNS, was seltsam ist, da es tatsächlich einen Eintrag für den Samba AD-Server in der Reverse-Zone gibt.

urr-deb-smbad.ville-urrugne.fr *** PDC ***[192.168.1.8:123]: die Standarddomäne...
ICMP: 0 ms
NTP-Verzögerung: +0,0000000 s Offset von urr-deb-smbad.********.fr
RefID: 200-177-190-109.dsl.ovh.fr [109.190.177.200]
Schicht: 3

Warnung:
Die umgekehrte Namensauflösung wird empfohlen. Es kann zu einem Fehler
kommen, da sich das Feld für die Zeitpaket-Referenz-ID zwischen verschiedenen
NTP-Implementierungen unterscheidet und möglicherweise keine IP-Adressen verwendet.

In den Windows-Protokollen finde ich Warnungen, die auf ein Verbindungsproblem zwischen den beiden Geräten hindeuten

Aufgrund eines Erkennungsfehlers konnte NtpClient keine verwendbare Peer-Domäne als Zeitquelle definieren. Der Vorgang wird in 15 Minuten wiederholt, anschließend wird das Timeout-Intervall für weitere Versuche verdoppelt. Die Fehlermeldung lautete: Thema nicht gefunden. (0x800706E1)

NtpClient-Zeitanbieter: Nach 8 Kontaktversuchen wurde keine gültige Antwort vom Domänencontroller urr-deb-smbad.********.fr empfangen. Dieser Domänencontroller wird als Zeitquelle abgelehnt, und NtpClient versucht, einen neuen Domänencontroller für die Synchronisierung zu ermitteln. Fehlermeldung: Gegenstelle nicht erreichbar.

Der Server antwortet korrekt auf Pings vom Client-Rechner.

Haben Sie eine Idee, was ich vergessen haben könnte?