[Samba] Time synchronization problem. Chrony, ntp

James Browning jamesb192 at jamesb192.com
Sun Jan 19 13:16:59 UTC 2025


On Sunday, January 19, 2025 2:19:05 AM Pacific Standard Time Rowland Penny via 
samba wrote:
> On Sun, 19 Jan 2025 10:55:57 +0100
> 
> Peter Milesson via samba <samba at lists.samba.org> wrote:
> > Hi folks,
> > 
> > In this discussion, I think the elephant in the room has not been
> > properly mentioned yet. That is NTP security for Windows clients in
> > Samba AD domains.
> > 
> > With the procedures proposed in this discussion, you get a working
> > time sync for Windows clients, but with no security whatsoever. What
> > does not work here (or intermittently works), is secure time sync of
> > Windows clients to a Samba DC with chrony, using signing. This is
> > what a Windows client expects, when getting its time from a AD DC
> > (w32tm /config /syncfromflags:DOMHIER). If the time sync response is
> > erroneous, the client reverts to using the local clock, which may, or
> > may not, have substantial drift. Over time, there will be more and
> > more cases where services get denied. Without security, you could
> > probably introduce a rouge NTP server that effectively renders the
> > whole domain inoperable for Windows clients, if working, secure NTP
> > services are not supplied by the DCs.
> > 
> > I am not in the position to put the blame on anybody, but it is
> > obvious that the failing components here are either Samba or chrony,
> > or a combination of both. With respect to constantly raised threat
> > levels, and (occasional) remedies, I feel it is finally time to
> > address this problem comprehensibly. This discussion has been popping
> > up occasionally during at least the last 10 years, and it really
> > would be nice to getting it resolved once and for all.
> > 
> > FYI, this is a link to the latest documentation about Windows time
> > sync from Microsoft:
> > https://winprotocoldocs-bhdugrdyduf5h2e4.b02.azurefd.net/MS-SNTP/%5bMS-SNT
> > P%5d.pdf
> > 
> > Intentionally I have not mentioned ntpsec, as it did not work almost
> > a year ago, and no updates have been published since (Debian).
> > 
> > Best regards,
> > 
> > Peter
> 
> This post mirrors what I have been thinking since yesterday, using a
> normal unsigned NTP server works, but using a signed NTP server
> doesn't.
> 
> It used to work, but as to when it stopped working is uncertain, what
> didn't help was when ntp was forked to ntpsec, the code to do the
> signing was removed (as stated by the person who wrote the secure
> connection between Samba and ntp), ntpsec denied they had removed it.
> Now, from my understanding, ntpsec claims to have fixed it, but the fix
> is only in the version of ntpsec found in Trixie.

Being the child of Omelas, everyone will beat on and abuse it. To firmly set 
the record less crooked: The ntp_signd.c file never went away, it just got 
worked over and unplugged. After I took a turn beating on it (adding error 
logging for the first time in forever), I asked for people to test it and got 
no reply. Oh, yeah, check the unenclosed git log or shut your keyboard about 
it.

> Did Chrony ever support signed time ? Have we been mis-advised all
> these years ?

Chrony added MS-SNTP support in 2016. There was one commit to the MS-SNTP code 
there back in April to change logging, and the change before that was in 2020.

----
ntp: log failed connection to Samba signd socket

Log an error message (in addition to the socket-specific debug message)
when the connection to signd socket fails, but only once before a
successful signd exchange to avoid flooding the system log.
----

Of course, nobody has the vertebrae to actually mention this to Miroslav.

> Does systemd-timesync support signing ? If not, should Samba be
> advising its use ?

It's a cheap and easy client to keep your clocks synced up as long as you 
presumably do not care about microseconds.

-30-







More information about the samba mailing list