Problemas de sincronización NTP para clientes

[Yaldoo]

Buen día,

Estoy en Debain 13 con la última versión de Samba-AD.
Seguí las instrucciones https://samba.tranquil.it/doc/fr/samba_...ebian.html
Tengo el servicio chrony ejecutándose, el socket tiene los permisos correctos, pero mi servidor no responde a las solicitudes firmadas (longitud 120)

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

Código: Seleccionar todo

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

Código: Seleccionar todo

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)

Recibo una respuesta en el primer caso pero no en el segundo.
Lo he intentado todo, pero nada funciona. ¿Alguna vez te has encontrado con este problema?

[dcardón]

Hola Julien,

Respecto de los DC, ¿Chrony dice que está muy contento con MS-SNTP?

Código: Seleccionar todo

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

y que no hay

Código: Seleccionar todo

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

Denis

[Yaldoo]

Gracias por sus respuestas. Los registros parecen estar bien en ambos controladores

Código: Seleccionar todo

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

Aunque no tengo un archivo de registro en /var/log/chrony

Intenté actualizar y reiniciar... nada funcionó

En su opinión, ¿puedo enviar un servidor NTP a través de GPO?

[dcardón]

Hola Julien,

por defecto, las estaciones de trabajo Windows funcionan en modo NTP NTDS5, lo que significa que se conectan a los controladores de dominio para NTP mediante un método seguro (SNTP) basado en la cuenta de Active Directory del equipo.

Si es necesario, puedes implementar un objeto de directiva de grupo (GPO) para que apunte a otros servidores NTP, pero en ese caso se utilizará NTP estándar en lugar de SNTP, lo cual no creo que sea un problema a menos que necesites una red con un alto nivel de seguridad.

En cualquier caso, el modo NTP NTDS5 debería funcionar sin problemas.

Saludos cordiales,

Denis

[plóubi]

Buen día,

Tengo un problema con las estaciones de trabajo de mis clientes (Windows), cuyos relojes no están sincronizados.
La configuración del servidor coincide con la documentación: https://samba.tranquil.it/doc/es/samba_ ...ebian.html
MS-SNTP parece estar activo

urr-deb-smbad:/home/urrugne# systemctl status chrony
● chrony.service - chrony, un cliente/servidor NTP
Cargado: cargado (/lib/systemd/system/chrony.service; habilitado; preestablecido: habilitado)
Activo: activo (en ejecución) desde el lunes 10 de agosto de 2026 15:39:16 CEST; Hace 1h 44min
Documentación: man:chronyd(8)
man:chronyc(1)
man:chrony.conf(5)
PID principal: 302393 (chronyd)
Tareas: 2 (límite: 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]: chronyd versión 4.3 iniciando (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
10 de agosto 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Frecuencia -39.237 +/- 0.007 ppm leída de /var/lib/chrony/chrony.drift
10 de agosto 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Usando la zona horaria derecha/UTC para obtener datos de segundos intercalares
10 de agosto 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Autenticación MS-SNTP habilitada
10 de agosto 15:39:16 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Filtro seccomp cargado (nivel 1)
10 de agosto 15:39:16 urr-deb-smbad.ville-urrugne.fr systemd[1]: Se inició chrony.service - chrony, un cliente/servidor NTP.
10 de agosto 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Fuente seleccionada 109.190.177.200 (2.debian.pool.ntp.org)
10 de agosto 15:39:21 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Desplazamiento TAI del reloj del sistema establecido en 37 segundos
10 de agosto 15:40:27 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Fuente seleccionada 217.154.21.219 (2.debian.pool.ntp.org)
10 de agosto 15:44:46 urr-deb-smbad.ville-urrugne.fr chronyd[302393]: Fuente seleccionada 109.190.177.200 (2.debian.pool.ntp.org)

En la configuración de Windows para que los clientes ajusten la hora, se especifica que algunas configuraciones son "administradas por mi organización"
Los botones "Sincronizar ahora" y "Editar servidor de hora" están activos, pero falla cuando intento modificarlos (tengo que salir de Active Directory para resincronizar manualmente y luego volver a unirme).

"w32tm /query /status" devuelve que estoy en Reloj CMOS local en lugar del servidor Samba AD
"w32tm.exe /query /configuration" devuelve que efectivamente estoy en NT5DS
Sin embargo, con "w32tm /monitor" parece que todo está bien, salvo una advertencia sobre el DNS inverso, lo cual es extraño porque de hecho hay una entrada para el servidor Samba AD en la zona inversa.

urr-deb-smbad.ville-urrugne.fr *** PDC ***[192.168.1.8:123]: el dominio predeterminado...
ICMP: 0 ms
Retraso NTP: +0,0000000 s Desplazamiento de urr-deb-smbad.********.fr
RefID: 200-177-190-109.dsl.ovh.fr [109.190.177.200]
Capa: 3

Advertencia:
Se recomienda la resolución inversa de nombres. Puede producirse un error
porque el campo ID de referencia del paquete de tiempo difiere entre
las implementaciones de NTP y puede que no utilice direcciones IP.

En los registros de Windows, tengo advertencias que parecen indicar un problema de conexión entre los dos

NtpClient no pudo definir un dominio de pares utilizable como fuente de hora debido a un error de detección. Reintentará en 15 minutos y, a continuación, duplicará el intervalo de tiempo de espera para los intentos posteriores. El error fue: Tema no encontrado. (0x800706E1)

Proveedor de hora de NtpClient: No se recibió respuesta válida del controlador de dominio urr-deb-smbad.********.fr tras 8 intentos de contacto. Este controlador de dominio será rechazado como fuente de hora y NtpClient intentará encontrar un nuevo controlador de dominio para sincronizar. Error notificado: El par es inaccesible.

El servidor responde correctamente a los pings de la máquina cliente.

¿Tienes alguna idea de qué pude haber olvidado?