samba - Aug 2023 - Samba domain time sync woes (Debian Bookworm)

On Wed, Aug 9, 2023 at 11:16?AM Luis Peromarta via samba <
samba at lists.samba.org> wrote:
> From
>
> https://wiki.samba.org/index.php/Time_Synchronisation
>
> "As a workaround for this, set the same external time servers on all
DC's,
> then if the PDC emulator goes offline and cannot easily be restarted,
> transfer or seize the PDC emulator role to another DC."
>
> I have all DCs configured with chrony to get time from external time
> servers, all with identical chrony config.
>
> Is this the right way to do it then ?
> On 9 Aug 2023 at 11:05 +0200, samba at lists.samba.org, wrote:
> >
> > All DCs get their time from the DC
> > that holds the PDC_Emulator FSMO role, which gets its time from an
> > external source.
> --
>
I think there may be some confusion here... The DCs time and how the DC
gets time is independent from Samba offering time on the client side. In
other words, it doesn't matter how your DC gets the time whether it is ntp
or ntpsec so just configure ntpsec (or crony or whatever else you want) so
that the server has the right time and then Samba will offer up that time.
As indicated, Samba doesn't actually give the time but more so the Windows
client sync's to an available DC based on Microsoft's implementation of
ntp. Now to my knowledge (and maybe I've been mistaken all this time) Samba
has it's own ntp service builtin which would not be affected by Bookworm
moving to ntpsec.

On 10.08.2023 18:13, Philippe LeCavalier via samba
wrote:
> On Wed, Aug 9, 2023 at 11:16?AM Luis Peromarta via samba <
> samba at lists.samba.org> wrote:
>
>> From
>>
>> https://wiki.samba.org/index.php/Time_Synchronisation
>>
>> "As a workaround for this, set the same external time servers on
all DC's,
>> then if the PDC emulator goes offline and cannot easily be restarted,
>> transfer or seize the PDC emulator role to another DC."
>>
>> I have all DCs configured with chrony to get time from external time
>> servers, all with identical chrony config.
>>
>> Is this the right way to do it then ?
>> On 9 Aug 2023 at 11:05 +0200, samba at lists.samba.org, wrote:
>>> All DCs get their time from the DC
>>> that holds the PDC_Emulator FSMO role, which gets its time from an
>>> external source.
>> --
>>
> I think there may be some confusion here... The DCs time and how the DC
> gets time is independent from Samba offering time on the client side. In
> other words, it doesn't matter how your DC gets the time whether it is
ntp
> or ntpsec so just configure ntpsec (or crony or whatever else you want) so
> that the server has the right time and then Samba will offer up that time.
> As indicated, Samba doesn't actually give the time but more so the
Windows
> client sync's to an available DC based on Microsoft's
implementation of
> ntp. Now to my knowledge (and maybe I've been mistaken all this time)
Samba
> has it's own ntp service builtin which would not be affected by
Bookworm
> moving to ntpsec.
Hi Philippe,

The problem was not that the DC holding the PDC emulator role could not 
sync with external NTP servers. In that respect ntpsec was working. With 
ntpsec on the DCs, the domain clients did not sync. With Chrony no 
problems at all.

As previously stated from multiple information sources (also from 
Microsoft), the DCs sync with the DC having the PDC emulator role. I 
assume this is valid for Samba also, but there are other people on the 
list who could give a definite answer. However, in the case of ntpsec, I 
suspect that the DCs not having the PDC emulator role, could not sync 
with the topmost DC either.

The Windows clients could be set to sync with whatever NTP server(s). 
Naturally, it's convenient to set them to sync with a DC in the domain 
automatically. But you could equally well define the NTP servers to use 
with a GPO.

IMHO, the Windows time hierarchy seems brain dead and vulnerable today. 
The whole concept is still mid-90's, when there was no internet outside 
major cities, or if there was, you maybe got 64 kbit/s at a huge cost. 
You set up your domain structure and put a card with a radio synced 
clock in the server, and had a local, reliable time source. No need to 
steal bandwidth from essential traffic, and the domain worked with, or 
without internet connection. The concept made sense then, but today it's 
definitely a dinosaur. Not to mention that Windows 10 clients still 
check NTP access by sending a NTP ver. 3 request to the NTP server, 
which ntpsec cannot interpret, and does not reply to.

Best regards,

Peter