On 20 January 2025 15:18 Luis Peromarta wrote:>
> I hope to be able to do the same kind of tests,
> On 20 Jan 2025 at 15:10 +0000, Peter Milesson <miles at atmos.eu>,
wrote:
> >
> > I have tested with Windows 7 Pro (SP1), Windows 10 Pro (22H2), and
> > Windows 11 Pro (24H2). All those clients report CMOS clock as time
> > source. I also suspect that something broke in Samba since I posted
> > about this problem on 9 August 2023. Then I was using Samba 4.17.9,
> > which worked when I switched from ntpsec to chrony.
> >
> > Maybe I will try to set up a test domain and install a DC from
Bookworm,
> > without backports. That will be Samba 4.17.12. The Windows 7 client
> > should probably work with that one. The latest Windows 10 and 11, will
> > probably not work, due to several changes since then. But that will
> > probably have to wait until the weekend.
I tested an old version of a bookworm dc with Samba version 4.17.5 and a Windows
10 Pro version 1903
The dc is running chrony version 4.3-1+b1. The Windows machine has no
amendments to its time settings, no GPO no registry settings, so when it was
joined to the domain the Type is NT5DS when w32tm /query /configuration command
is run. Ie it's out of the box. With this setup the time synchronisation
works OK, with the w32tm /query /status giving successful result and citing the
dc as its source.
I then removed the Windows machine from that domain and joined it to a domain
where its dc is running Samba version 4.21.3 and Chrony 4.3-2. Made no changes
to the time settings and the w32tm /query /configuration command indicated that
the Type is still NT5DS but the status shows the source as Local CMOS clock and
the last successful sync is unspecified.
This seems to confirm that something has changed between Samba 4.17.x and 4.21.
As others have stated, to get it to work with current versions of samba, the
Type has to be set to NTP and to specify a DC as source on Windows machines.
HTH,
Roy