Problemi di sincronizzazione NTP per i client

[yaldoo]

Buongiorno,

Utilizzo Debain 13 con l'ultima versione di Samba-AD.
Ho seguito le istruzioni https://samba.tranquil.it/doc/fr/samba_...ebian.html
Ho il servizio Chrony in esecuzione, il socket ha le autorizzazioni corrette, ma il mio server non risponde alle richieste firmate (lunghezza 120)

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

Codice: Seleziona tutto

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

Codice: Seleziona tutto

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)

Nel primo caso ricevo una risposta, ma non nel secondo.
Ho provato di tutto, ma niente funziona. Hai mai riscontrato questo problema?

[dcardon]

Ciao Julien,

Per quanto riguarda i DC, Chrony dice di essere molto soddisfatto di MS-SNTP?

Codice: Seleziona tutto

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

e che non c'è

Codice: Seleziona tutto

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

Denis

[yaldoo]

Grazie per le risposte. I log sembrano a posto su entrambi i miei DC

Codice: Seleziona tutto

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

Tuttavia non ho un file di registro in /var/log/chrony

Ho provato ad aggiornare e riavviare... niente ha funzionato

Secondo te, posso eseguire il push di un server NTP tramite GPO?

[dcardon]

Ciao Julien,

di default le workstation Windows funzionano in modalità NTP NTDS5, il che significa che si connettono ai controller di dominio per il protocollo NTP utilizzando un metodo sicuro (SNTP) basato sull'account di Active Directory della macchina.

Se necessario, è possibile implementare un oggetto Criteri di gruppo (GPO) per puntare ad altri server NTP, ma in tal caso si utilizzerà il protocollo NTP standard anziché SNTP, il che non credo rappresenti un problema a meno che non sia necessaria una rete con un elevato livello di sicurezza.

In ogni caso, la modalità NTP NTDS5 dovrebbe funzionare senza problemi...

Cordiali saluti,

Denis

[ploubi]

Buongiorno,

Ho un problema con le workstation dei miei clienti (Windows) i cui orologi non si sincronizzano.
La configurazione del server corrisponde alla documentazione: https://samba.tranquil.it/doc/it/samba_ ...ebian.html
MS-SNTP sembra essere attivo

urr-deb-smbad:/home/urrugne# systemctl status chrony
● chrony.service - chrony, un client/server NTP
Caricato: caricato (/lib/systemd/system/chrony.service; abilitato; preimpostazione: abilitato)
Attivo: attivo (in esecuzione) da lun 10-08-2026 15:39:16 CEST; 1h 44min ago
Documenti: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
PID principale: 302393 (chronyd)
Attività: 2 (limite: 4562)
Memoria: 1,5M
CPU: 91ms
CGroup: /system.slice/chrony.service
├─302393 /usr/sbin/chronyd -F 1
└─302394 /usr/sbin/chronyd -F 1 10

ago 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: avvio della versione 4.3 di chronyd (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
10 ago 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Frequenza -39.237 +/- 0.007 ppm letta da /var/lib/chrony/chrony.drift
10 ago 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Utilizzo del fuso orario right/UTC per ottenere i dati del secondo intercalare
10 ago 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Autenticazione MS-SNTP abilitata
10 ago 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Filtro seccomp caricato (livello 1)
10 ago 15:39:16 urr-deb-smbad.ville-urrugne.fr systemd[1]: Avviato chrony.service - chrony, un client/server NTP.
10 ago 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Sorgente selezionata 109.190.177.200 (2.debian.pool.ntp.org)
10 ago 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Offset TAI dell'orologio di sistema impostato a 37 secondi
10 ago 15:40:27 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Sorgente selezionata 217.154.21.219 (2.debian.pool.ntp.org)
10 ago 15:44:46 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Sorgente selezionata 109.190.177.200 (2.debian.pool.ntp.org)

Nelle impostazioni di Windows per i client, relative alla regolazione dell'ora, è specificato che alcune impostazioni sono "gestite dalla mia organizzazione"
I pulsanti "Sincronizza ora" e "Modifica server orario" sono attivi, ma la modifica fallisce (devo uscire da Active Directory per risincronizzare manualmente e poi rientrare).

"w32tm /query /status" restituisce che sono in Orologio CMOS locale invece del server Samba AD
"w32tm.exe /query /configuration" restituisce che sono effettivamente in NT5DS
Con "w32tm /monitor" sembra invece tutto a posto, a parte un avviso relativo al DNS inverso, il che è strano perché effettivamente esiste una voce per il server Samba AD nella zona inversa.

urr-deb-smbad.ville-urrugne.fr *** PDC ***[192.168.1.8:123]: il dominio predefinito...
ICMP: 0ms
Ritardo NTP: +0.0000000s Offset di urr-deb-smbad.********.fr
RefID: 200-177-190-109.dsl.ovh.fr [109.190.177.200]
Livello: 3

Avviso:
si consiglia la risoluzione inversa del nome. Potrebbe
verificarsi un errore perché il campo ID di riferimento del pacchetto temporale differisce tra
le implementazioni NTP e potrebbe non utilizzare indirizzi IP.

Nei registri di Windows ho degli avvisi che sembrano indicare un problema di connessione tra i due

NtpClient non è riuscito a definire un dominio peer utilizzabile come sorgente oraria a causa di un errore di rilevamento. Riproverà tra 15 minuti, quindi raddoppierà l'intervallo di timeout per i tentativi successivi. L'errore è stato: Argomento non trovato. (0x800706E1)

Provider orario NtpClient: non è stata ricevuta alcuna risposta valida dal controller di dominio urr-deb-smbad.********.fr dopo 8 tentativi di contatto. Questo controller di dominio verrà rifiutato come sorgente oraria e NtpClient tenterà di individuare un nuovo controller di dominio da cui sincronizzarsi. Errore segnalato: il peer non è raggiungibile.

Il server risponde correttamente ai ping provenienti dal computer client.

Avete idea di cosa potrei aver dimenticato?