[Samba] Joining Windows 10 Domain Member to Samba AD/DC
Peter Milesson
miles at atmos.eu
Sat Feb 10 20:27:27 UTC 2024
On 10.02.2024 20:19, Mark Foley via samba wrote:
> On Sat Feb 10 04:36:35 2024 Peter Milesson via samba <samba at lists.samba.org> wrote:
>> Hi Mark,
>>
>> The NTP requests from linux hosts to time servers do not contain extra
>> fields, just the basic fields that are required. Windows clients tack
>> another 20 bytes to the NTP request. See the following article from M$:
>>
>> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/824d0b97-59e7-405c-8e0d-7b18b6304d10
>>
>> chrony should work without any problems. Below, I have listed the
>> contents of my chrony.conf file, just for comparison. This configuration
>> works in several domains at the moment. I do not use any chrony keys,
>> though there is an empty file. The file is owned by root:_chrony 0640.
>>
>> You will probably need to assign user _chrony and group _chrony.
>> /var/lib/chrony is owned by _chrony:_chrony 0750. There is also
>> /var/run/chrony owned by _chrony:_chrony 0700.
>>
>> Hope that you sort it out.
>>
>> Peter
>>
>>
>> # Welcome to the chrony configuration file. See chrony.conf(5) for more
>> # information about usable directives.
>>
>> # Include configuration files found in /etc/chrony/conf.d.
>> confdir /etc/chrony/conf.d
>>
>> # Use Debian vendor zone.
>> pool 2.debian.pool.ntp.org iburst
>>
>> # Use time sources from DHCP.
>> sourcedir /run/chrony-dhcp
>>
>> # Use NTP sources found in /etc/chrony/sources.d.
>> sourcedir /etc/chrony/sources.d
>>
>> # This directive specify the location of the file containing ID/key
>> pairs for
>> # NTP authentication.
>> keyfile /etc/chrony/chrony.keys
>>
>> # This directive specify the file into which chronyd will store the rate
>> # information.
>> driftfile /var/lib/chrony/chrony.drift
>>
>> # Save NTS keys and cookies.
>> ntsdumpdir /var/lib/chrony
>>
>> # Uncomment the following line to turn logging on.
>> #log tracking measurements statistics
>>
>> # Log files location.
>> logdir /var/log/chrony
>>
>> # Stop bad estimates upsetting machine clock.
>> maxupdateskew 100.0
>>
>> # This directive enables kernel synchronisation (every 11 minutes) of the
>> # real-time clock. Note that it can't be used along with the 'rtcfile'
>> directive.
>> rtcsync
>>
>> # Step the system clock instead of slewing it if the adjustment is
>> larger than
>> # one second, but only in the first three clock updates.
>> makestep 1 3
>>
>> # Get TAI-UTC offset and leap seconds from the system tz database.
>> # This directive must be commented out when using time sources serving
>> # leap-smeared time.
>> leapsectz right/UTC
>>
>> bindcmdaddress 172.16.0.100
>>
>> allow 172.16.0.0/24
>>
>> ntpsigndsocket /var/lib/samba/ntp_signd
>>
> Thanks Peter. It's clear that ntpd is not responding to the signing requests from
> the Windows computers, though I am certain I built it with --enable-ntp-signd.
> Unfortnately, there is no way to verify it was built that way.
>
> However, chrony just isn't working for me. Here's my /etc/chrony/chrony.conf:
>
> ----------------------------
> bindcmdaddress 192.168.0.2
>
> server 0.pool.ntp.org iburst
> server 1.pool.ntp.org iburst
> server 2.pool.ntp.org iburst
>
> allow 192.168.0.0/24
> logdir /var/log/chrony
> keyfile /etc/chrony/chrony.keys
> makestep 1 3
> hwclockfile /etc/adjtime
> ntpsigndsocket /var/lib/samba/ntp_signd
> -----------------------------
>
> /var/lib/samba/ntp_signd is owned by group chrony. It's timestamp is unchanged
> after starting chrony.
>
> /var/lib/chrony is owned by chrony.chrony.
> /var/run/chrony owned by chrony.chrony.
>
> I start chrony with:
>
> /usr/sbin/chronyd -f /etc/chrony/chrony.conf
>
> chrony responds fine to the pool.ntp.org servers, but running tcpdump, shows
> that chrony simply doesn't respond to queries from the Windows domain members:
>
> # tcpdump -v -l -i eth0 port 123
> 13:37:05.687333 IP (tos 0x0, ttl 128, id 13312, offset 0, flags [none], proto UDP (17), length 96)
> 192.168.0.52.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: 3916134665.288999699 (2024-02-05T15:11:05Z)
> Originator Timestamp: 0.000000000
> Receive Timestamp: 0.000000000
> Transmit Timestamp: 3916579000.023001399 (2024-02-10T18:36:40Z)
> Originator - Receive Timestamp: 0.000000000
> Originator - Transmit Timestamp: 3916579000.023001399 (2024-02-10T18:36:40Z)
> Key id: 1694760960
> Authentication: 00000000000000000000000000000000
>
> The "Key id:" and "Authentication:" fields have to do with the ntp-signd
> authentication. chrony sends no response back to 192.168.0.52 or any other
> Windows computer.
>
> Is there something wrong with my config?
>
> Does chrony have to be built in some special way to enable ntp-signd?
>
> If you run 'tcpdump -v -l -i ethX port 123' on your DC, does it show sending a
> response back to your Windows computers?
>
> Thanks --Mark
>
Hi Mark,
I haven't got a clue about how chrony should be built, as I'm just
managing it through the Debian package system. But it's possible to get
the build scripts from different linux distributions and check how the
different packages are built. As signing is required, I guess there must
be some cryptographic libraries involved when building. Maybe that's the
failing point for ntpd in your setup also? Have you checked the logs, if
chrony crashes or something like that?
Are there multiple interfaces on your DC? In that case, chrony may be
listening on the wrong one?
Do chronyd.pid and chronyd.sock in /var/run/chrony exist? Does chrony
respond to requests from linux boxes?
Note that the parameter ntpsigndsocket /var/lib/samba/ntp_signd is not a
file, but a directory. That is described in the Samba wiki.
I guess something is wrong either with permissions, or some missing
prerequisite. Chrony should definitely respond to requrests.
Below is the result from running 'tcpdump -v -l -i enp1s0 port 123' in
my home DC, when starting up a Windows 11 VM.
Best regards,
Peter
tcpdump: listening on enp1s0, link-type EN10MB (Ethernet), snapshot
length 262144 bytes
20:46:02.750781 IP (tos 0x0, ttl 128, id 7518, offset 0, flags [none],
proto UDP (17), length 96)
172.16.0.9.ntp > homeadc.private.talps.ntp: NTPv3, Client, length 68
Leap indicator: clock unsynchronized (192), Stratum 0
(unspecified), poll 17 (131072s), precision -23
Root Delay: 0.000000, Root dispersion: 1.000000, Reference-ID:
(unspec)
Reference Timestamp: 3916586729.816018999 (2024-02-10T20:45:29Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3916586762.675073599 (2024-02-10T20:46:02Z)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3916586762.675073599
(2024-02-10T20:46:02Z)
Key id: 1828978688
Authentication: 00000000000000000000000000000000
20:46:02.751238 IP (tos 0x0, ttl 64, id 21741, offset 0, flags [DF],
proto UDP (17), length 96)
homeadc.private.talps.ntp > 172.16.0.9.ntp: NTPv3, Server, length 68
Leap indicator: (0), Stratum 2 (secondary reference), poll 17
(131072s), precision -25
Root Delay: 0.010375, Root dispersion: 0.002441, Reference-ID:
0x4e6c60c5
Reference Timestamp: 3916582849.251213464 (2024-02-10T19:40:49Z)
Originator Timestamp: 3916586762.675073599 (2024-02-10T20:46:02Z)
Receive Timestamp: 3916583162.750204540 (2024-02-10T19:46:02Z)
Transmit Timestamp: 3916583162.750317928 (2024-02-10T19:46:02Z)
Originator - Receive Timestamp: -3599.924869059
Originator - Transmit Timestamp: -3599.924755671
Key id: 1828978688
Authentication: f4a4d5849bfbc23d74e636aff69bc27d
More information about the samba
mailing list