[Samba] Time synchronization problem. Chrony, ntp

Luis Peromarta
2025-01-19T10:45:57Z

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