On Fri Feb 9 12:14:31 2024 Mark Foley via samba <samba at
lists.samba.org> wrote:>
> On Fri Feb 9 12:02:47 2024 Peter Milesson via samba <samba at
lists.samba.org> wrote:
> >
> > On 09.02.2024 17:02, Mark Foley via samba wrote:
> > > On Fri Feb 9 04:23:29 2024 Luis Peromarta via samba<samba at
lists.samba.org> wrote:
> > >> Are your clients talking to the DCs re. Time at all ?
> > >>
> > >> This is an example in one of my DCs: Run tcpdump on your DC:
> > >>
> > >> root at dwing:~# tcpdump??port 123 -v
> > >> [snip]
> > >>
> > >> Might be work examining that traffic for clues.
> > >>
> > >> Regards, LP
> > > Luis, excellent suggestion! Below is my result:
> > >
> > > --------------------------
> > > # tcpdump -v -i eth0 port 123
> > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot
length 262144 bytes
> > > 10:23:07.468629 IP (tos 0x0, ttl 128, id 22607, offset 0, flags
[none], proto UDP (17), length 96)
> > > 192.168.0.53.ntp > mail.hprs.local.ntp: NTPv3, Client,
length 68
> > > Leap indicator: clock unsynchronized (192), Stratum 0
(unspecified), poll 7 (128s), precision -23
> > > Root Delay: 0.000000, Root dispersion: 1.000000,
Reference-ID: (unspec)
> > > Reference Timestamp: 3916127270.315146199
(2024-02-05T13:07:50Z)
> > > Originator Timestamp: 0.000000000
> > > Receive Timestamp: 0.000000000
> > > Transmit Timestamp: 3916480949.611151499
(2024-02-09T15:22:29Z)
> > > Originator - Receive Timestamp: 0.000000000
> > > Originator - Transmit Timestamp:
3916480949.611151499 (2024-02-09T15:22:29Z)
> > > Key id: 1711538176
> > > Authentication: 00000000000000000000000000000000
> > > 10:23:07.468836 IP (tos 0xb8, ttl 64, id 2268, offset 0, flags
[DF], proto UDP (17), length 80)
> > > mail.hprs.local.ntp > 192.168.0.53.ntp: NTPv3, Server,
length 52
> > > Leap indicator: (0), Stratum 3 (secondary reference),
poll 7 (128s), precision -19
> > > Root Delay: 0.035171, Root dispersion: 0.085723,
Reference-ID: 0x179da0a8
> > > Reference Timestamp: 3916479890.214796580
(2024-02-09T15:04:50Z)
> > > Originator Timestamp: 3916480949.611151499
(2024-02-09T15:22:29Z)
> > > Receive Timestamp: 3916480987.468629691
(2024-02-09T15:23:07Z)
> > > Transmit Timestamp: 3916480987.468801127
(2024-02-09T15:23:07Z)
> > > Originator - Receive Timestamp: +37.857478191
> > > Originator - Transmit Timestamp: +37.857649627
> > > Key id: 0
> > > ^C
> > > 4 packets captured
> > > 5 packets received by filter
> > > 0 packets dropped by kernel
> > > -----------------------------------
> > >
> > > Host 192.168.0.53 is a Windows 10 domain member. On that
computer, I get:
> > >
> > > C:\Users\Administrator.HPRS>w32tm /query /source
> > > Free-running System Clock
> > >
> > > C:\Users\Administrator.HPRS>w32tm /query /status
> > > Leap Indicator: 3(not synchronized)
> > > Stratum: 0 (unspecified)
> > > Precision: -23 (119.209ns per tick)
> > > Root Delay: 0.0000000s
> > > Root Dispersion: 0.0000000s
> > > ReferenceId: 0x00000000 (unspecified)
> > > Last Successful Sync Time: unspecified
> > > Source: Free-running System Clock
> > > Poll Interval: 10 (1024s)
> > >
> > > Some Windows computers come back with "Free-running System
Clock", most with
> > > "Local CMOS Clock", not sure what the difference is.
> > >
> > > However, the interesting bit is that the DC is getting time-sync
requests from
> > > this Windows computer, and apparently responding. So why
doesn't the /query show
> > > that?
> > >
> > > I am also able to show connection from Windows to the DC by
running
> > >
> > > w32tm /stripchart /computer:mail.hprs.local /dataonly /samples:5
> > >
> > > I'm going to let the tcpdump run for a while to see if the
other Windows
> > > computers show up.
> > >
> > > Thanks --Mark
> > >
> > >> On Feb 9, 2024 at 05:31 +0100, Mark Foley via samba<samba
at lists.samba.org>, wrote:
> > >>> On Thu Jan 4 19:46:02 2024 Mark Foley via samba<samba
at lists.samba.org> wrote:
> > >>>> I've added a Windows 10 domain member to my
Domain. I'm now following the
> > >>>> procedure
inhttps://wiki.samba.org/index.php/Time_Synchronisation#Configuring_Time_Synchronisation_on_a_Windows_Domain_Member.
> > >>>>
> > >>>> [deleted]
> > >>> The above references the first in a long thread I started
having to do with
> > >>> getting a Windows domain member to time-sync with a new
DC, Samba 4.18.9.
> > >>>
> > >>> None of my Windows domain members sync with the new
domain controller.
> > >>>
> > >>> None of these same Windows workstation had any problem
syncing with the previous
> > >>> Samba 4.8.2 DC which ran for the past 10-ish years.
> > >>>
> > >>> On th DC I've tried both chrony and ntp-4.2.8. In the
ntp case I used the same
> > >>> 4.8.2 version on the old DC; in both cases built with
--enable-ntp-signd.
> > >>>
> > >>> One possible issue was that these Windows domain members
were unjoined from the
> > >>> 4.8.2 domain, rejoined to the new 4.18.9, and had
Profwiz.exe run on each member
> > >>> to migrate the domain user's profile. None of that
was done when they were
> > >>> first joined to the old 4.8.2 domain. One participant in
this thread suggested
> > >>> I try joining a "virgin" Windows computer. I
did that today with a scratch
> > >>> install of Windows 10.
> > >>>
> > >>> After joining the domain I got:
> > >>>
> > >>> w32tm /query /source
> > >>> Local CMOS Clock
> > >>>
> > >>> I hoping for the FQDN of the DC:
'mail.hprs.local', like I used to get with
> > >>> Samba 4.8.2.
> > >>>
> > >>> This is the same thing I have been getting from the
beginning with the new
> > >>> 4.18.9 DC. Several thread participants said I
shouldn't need to do any group
> > >>> policies or anything special. Apparently in my case this
is not true.
> > >>>
> > >>> Everything configured is strictly "vanilla".
The DC was provisioned as:
> > >>>
> > >>> samba-tool domain provision --use-rfc2307
--realm=HPRS.LOCAL --domain=HPRS \
> > >>> --server-role=dc --dns-backend=SAMBA_INTERNAL \
> > >>> --option=interfaces="lo eth0"
--option="bind interfaces only=yes"
> > >>>
> > >>> Nothing else was done on the DC. The "test"
Windows 10 computer was clean
> > >>> installed today, nothing left over from any previous
domain joins or old domain
> > >>> user profiles.
> > >>>
> > >>> I've tried with and without a "Time
Sources" GPO. At the moment, I have a GPO
> > >>> configured.
> > >>>
> > >>> There are only two differences I can identify between
when this worked and when
> > >>> it did not:
> > >>>
> > >>> 1. It worked with Samba 4.8.2 and does not work with
Samba 4.18.9.
> > >>>
> > >>> 2. Samba 4.8.2 was provisioned with
--dns-backend=BIND9_FLATFILE and Samba
> > >>> 4.18.9 was provisioned with --dns-backend=SAMBA_INTERNAL.
> > >>>
> > >>> Those, I believe, are the only differences. Something
must not be working
> > >>> correctly with Samba 4.18.9.
> > >>>
> > >>> As time-sync among domain members is supposed to be
critical, I am about to get
> > >>> Microsoft involved.
> > >>>
> > >>> Before I do that (and before I retry a bunch of the w32tm
commands), I'd like to
> > >>> see if any of the experts on this list have any
additional suggestion.
> > >>>
> > >>> Thanks --Mark
> > >>>
> > >>>
> > Hi Mark,
> >
> > The NTP server response is fishy. The request from your Windows
machine
> > is 68 bytes in length, and the response is 52 bytes. The response must
> > be the same size as the request, otherwise the response is invalid. If
I
> > don't remember completely wrong, I had some trouble with that
(Slackware
> > NT4 domain server), but it's more than 15 years back. You're
running
> > Slackware, I suppose? Get some recent NTP server source code and
compile
> > (not ntpsec, it doesn't work).
> >
> > Best regards,
> >
> > Peter
>
> Yes, I had already downloaded and built ntp-4.2.8p17 with
--enable-ntp-signd. This
> is mostly the same version of ntp I ran on my old DC Samba version 4.8.2
which
> ran perfectly for the past 10 years -- although that version was p15 no
p18.
>
> Yes, Slackware.
>
> But, that's interesting about the response appearing to be short.
I'll see if I
> can research any info on that.
>
> --Mark
I've done more testing. Not sure this is a Samba issue at this point, but
Luis
and Peter have opened up some possibilities ...
I've replaced ntp 4.2.8 with chrony 4.2, then ran 'tcpdump -i eth0 port
123:
WITH CHRONY
00:13:05.096520 IP mail.hprs.local.44657 > pacific.latt.net.ntp: NTPv4,
Client, length 48
00:13:05.163667 IP pacific.latt.net.ntp > mail.hprs.local.44657: NTPv4,
Server, length 48
00:13:16.365736 IP 192.168.0.60.ntp > mail.hprs.local.ntp: NTPv3, Client,
length 68
00:13:28.950106 IP 192.168.0.3.ntp > mail.hprs.local.ntp: NTPv4, Client,
length 48
00:13:34.035171 IP 192.168.0.4.ntp > mail.hprs.local.ntp: NTPv3, Client,
length 68
What's interesting is that the DC solicits and receives time info from the
pool.ntp.org server (pacific.latt.net.ntp) using NTPv4 and the packets are the
same length, 48, lending credibility to Peter's comment.
The Windows 10 computers (192.168.0.60 and 192.168.0.4) are using NTPv3 and
soliciting with a packet length of 68. The Windows packet length and NTP
version are different from that of the DC and Linux host, and from the NTP pool
hosts.
The non-domain member Linux computer (192.168.0.3) solicits using NTPv4 and a
packet length of 48.
However, the DC (mail.hprs.local.ntp) makes no responses to either the Windows
or
Linux clients.
Running stripchart on a Windows domain member gives errors:
C:\Users\Administrator.HPRS>w32tm /stripchart /computer:mail.hprs.local
/dataonly /samples:5
Tracking mail.hprs.local [192.168.0.2:123].
Collecting 5 samples.
The current time is 2/9/2024 11:57:41 PM.
23:57:41, error: 0x800705B4
23:57:44, error: 0x800705B4
23:57:47, error: 0x800705B4
23:57:50, error: 0x800705B4
23:57:53, error: 0x800705B4
Putting ntpd back on the DC gives:
WITH NTPD
01:14:29.564528 IP mail.hprs.local.ntp > hc-007-ntp1.weber.edu.ntp: NTPv4,
Client, length 48
01:14:29.633615 IP hc-007-ntp1.weber.edu.ntp > mail.hprs.local.ntp: NTPv4,
Server, length 48
01:14:34.433914 IP 192.168.0.55.ntp > mail.hprs.local.ntp: NTPv3, Client,
length 68
01:14:34.434149 IP mail.hprs.local.ntp > 192.168.0.55.ntp: NTPv3, Server,
length 52
01:14:40.688178 IP 192.168.0.60.ntp > mail.hprs.local.ntp: NTPv3, Client,
length 68
01:14:40.688411 IP mail.hprs.local.ntp > 192.168.0.60.ntp: NTPv3, Server,
length 52
01:14:41.969886 IP 192.168.0.3.ntp > mail.hprs.local.ntp: NTPv4, Client,
length 48
01:14:41.970114 IP mail.hprs.local.ntp > 192.168.0.3.ntp: NTPv4, Server,
length 48
01:14:43.945331 IP 192.168.0.3.ntp > mail.hprs.local.ntp: NTPv4, Client,
length 48
Again, communications between DC and ntp.pool uses NTPv4 and 48 byte packet
length.
The Windows domain members (192.168.0.55 and 60) continue to solicit with NTPv3
and 68 byte packet length, but unlike chrony, ntpd does reply with a NTPv3 52
byte packet. Per Peter, not sure if that's working. (192.168.0.55 /query
/source gives "Free runnung system clock")
In this case ntpd on the DC is responding to the Linux non-domain member
(192.168.0.3)
with NTPv4 and 48 byte packet. Running this same tcpdump command on 19.168.0.3
shows it communicating OK with the DC.
Running stripchart on a Windows domain member gives:
C:\Users\Administrator.HPRS>w32tm /stripchart /computer:mail.hprs.local
/dataonly /samples:5
Tracking mail.hprs.local [192.168.0.2:123].
Collecting 5 samples.
The current time is 2/10/2024 12:03:13 AM.
00:03:13, -00.0956615s
00:03:15, -00.0961509s
00:03:17, -00.0967269s
00:03:19, -00.0971766s
00:03:21, -00.0976874s
So, the Windows computers *can* connect to the DC ntpd server.
One thing seems apparent is that ntpd does a better job of communication with
domain computers than chrony. In fact, chrony responded to no domain computer,
Windows or Linux whereas ntpd responds to both.
However the different NTP protocol versions and packet sizes do appear to be a
problem. Particularly Windows with its v3 and 68 byte packet does not correspond
with the version and packet sizes used by Linux or ntp.pool servers. In fact,
when I switch my DC ntpd server to time.windows.com, it too is 48 bytes, but
NTPv3.
Setting 'version 3' in ntp.conf appears to have no effect.
A lot of information, but does this tell anyone anything?
more info ...
and after writing all that, I got curious about the extra length in the Windows
packet and saw that it is sending a Key Id (see verbose dump at top).
Seaching I found this:
The Windows Time source authenticates with a time source client. In an Active
Directory forest, the Windows Time service (W32time) relies on standard domain
security features to enforce the authentication of time data. The security of
Network Time Protocol (NTP) packets that are sent between a domain member and a
local domain controller that is acting as a time server is based on shared key
authentication. The Windows Time service uses the local computer's Kerberos
session key to create authenticated signatures on NTP packets that are sent
across the network. When a computer requests the time from a domain controller
in the domain hierarchy, the Windows Time service requires that the time be
authenticated. The domain controller then returns the required information in
the form of a 64-bit value that has been authenticated with the session key from
the NetLogon service. If the returned NTP packet is not signed with the
computerbs session key or if it is not signed correctly, the time is rejected.
In this way, the Windows Time service provides security for NTP data in an
Active Directory forest.
https://serverfault.com/questions/634726/windows-server-ntp-authenication
This may be my problem?
Thanks --Mark