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-SNTP%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. Did Chrony ever support signed time ? Have we been mis-advised all these years ? Does systemd-timesync support signing ? If not, should Samba be advising its use ? Rowland
My clients are using NT5DS secure ntp with Chrony and Samba 4.21.3 didn?t have any issue, see "Type: NT5DS (Local)? hereunder. C:\Windows\system32>w32tm /query /configuration [Configuration] EventLogFlags: 2 (Local) AnnounceFlags: 10 (Local) TimeJumpAuditOffset: 28800 (Local) MinPollInterval: 10 (Local) MaxPollInterval: 15 (Local) MaxNegPhaseCorrection: 4294967295 (Local) MaxPosPhaseCorrection: 4294967295 (Local) MaxAllowedPhaseOffset: 300 (Local) FrequencyCorrectRate: 4 (Local) PollAdjustFactor: 5 (Local) LargePhaseOffset: 50000000 (Local) SpikeWatchPeriod: 900 (Local) LocalClockDispersion: 10 (Local) HoldPeriod: 5 (Local) PhaseCorrectRate: 1 (Local) UpdateInterval: 30000 (Local) [TimeProviders] NtpClient (Local) DllName: C:\Windows\system32\w32time.dll (Local) Enabled: 1 (Local) InputProvider: 1 (Local) CrossSiteSyncFlags: 2 (Local) AllowNonstandardModeCombinations: 1 (Local) ResolvePeerBackoffMinutes: 15 (Local) ResolvePeerBackoffMaxTimes: 7 (Local) CompatibilityFlags: 2147483648 (Local) EventLogFlags: 1 (Local) LargeSampleSkew: 3 (Local) SpecialPollInterval: 3600 (Local) Type: NT5DS (Local) VMICTimeProvider (Local) DllName: C:\Windows\System32\vmictimeprovider.dll (Local) Enabled: 1 (Local) InputProvider: 1 (Local) NtpServer (Local) DllName: C:\Windows\system32\w32time.dll (Local) Enabled: 0 (Local) InputProvider: 0 (Local) On 19 Jan 2025 at 10:19 +0000, Rowland Penny via samba <samba at lists.samba.org>, 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-SNTP%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. > > Did Chrony ever support signed time ? Have we been mis-advised all > these years ? > > Does systemd-timesync support signing ? If not, should Samba be > advising its use ? > > Rowland > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
> Does systemd-timesync support signing ? If not, should Samba be > advising its use ?systemd-timesync provides only a cliente. Doesn't Samba need a time server?
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-