The MS-SNTP specification includes a new extended authenticator field, which is apparently used by w32time in latest Windows versions. It's not supported by ntp_signd yet. Latest versions of the specification are here: https://msdn.microsoft.com/en-us/library/cc246877.aspx A support for ntp_signd was recently implemented in chrony and it can detect MS-SNTP packets using the new extended authenticator field, but there is no way to pass the additional data to ntp_signd. A new command or version of the protocol will probably need to be specified.
Still present in Samba 4.24.6 — and now breaks Windows Server 2025 by default Confirming this five years on, with a minimal reproducer. Environment - Samba 4.24.6, AD DC (server role = active directory domain controller), Arch Linux - chrony 4.8 (+SIGND), ntpsigndsocket /var/lib/samba/ntp_signd - Client: Windows Server 2025 Standard, 10.0.26100.32995, domain member, w32time in default NT5DS mode Symptom The client never synchronizes and falls back to Local CMOS Clock: Event ID 24, Microsoft-Windows-Time-Service, Warning Time Provider NtpClient: No valid response has been received from domain controller server.rattotest.local after 8 attempts to contact it. This domain controller will be discarded as a time source... The error was: The peer is unreachable. The DC receives the requests (chronyc clients counts them, zero dropped) but sends no reply at all — not even an unsigned one. Nothing is logged by either component. smbcontrol all debug 10 produces no ntp_signd output, confirming chrony never forwards the request. The request on the wire IP 192.168.130.6.123 > 192.168.130.10.123: NTPv3, Client, length 120 0x1C-0x4B 48 bytes NTP header (LI=3, VN=3, Mode=3) 0x4C-0x4F 4 bytes Key Identifier = 37 08 00 00 (LE) = 2103 0x50-0x93 68 bytes signature field, zero-filled Key ID 2103 is the client's machine-account RID — S-1-5-21-…-2103 = GUI$. Per [MS-SNTP] §2.2, the ExtendedAuthenticator is 576 bits, giving a 120-byte message, versus the 160-bit Authenticator giving 68 bytes. Minimal reproducer Three UDP probes against the Samba DC isolate it precisely: import socket, struct TARGET = ("<dc-ip>", 123) RID = <client machine account RID> def probe(name, payload): s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.settimeout(4) try: s.sendto(payload, TARGET); r, _ = s.recvfrom(2048) print("%-34s sent %3d -> REPLY %d bytes" % (name, len(payload), len(r))) except socket.timeout: print("%-34s sent %3d -> NO REPLY" % (name, len(payload))) hdr = bytearray(48); hdr[0] = 0xdb; hdr[2] = 6; hdr[3] = 0xe9 hdr = bytes(hdr); keyid = struct.pack("<I", RID) probe("plain NTP (48)", hdr) probe("Authenticator (48+4+16)", hdr + keyid + b"\x00"*16) probe("ExtendedAuthenticator (48+4+68)", hdr + keyid + b"\x00"*68) Result: plain NTP (48) sent 48 -> REPLY 48 bytes Authenticator (48+4+16) sent 68 -> REPLY 68 bytes ExtendedAuthenticator (48+4+68) sent 120 -> NO REPLY The 68-byte reply is genuinely signed by Samba — key id 2103, crypto-checksum 726f2562d67e50a4f28105998ccb6fe5, and chronyd's connection count to the signd socket increases when it is produced. So the classic signing path is fully functional; only the extended form fails. Impact In 2021 this affected "modern w32time" opportunistically. Windows Server 2025 sends the ExtendedAuthenticator form by default, so a Samba AD DC is now unusable as a time source for current Windows clients in NT5DS mode. Because the DC still advertises TIMESERV/GTIMESERV in its DC-locator flags, clients continue selecting it and stall through 8 retries before failing over — in a two-DC domain with one Windows DC, that adds tens of minutes of Kerberos-relevant clock skew after every reboot. The failure is completely silent on the Samba side.