[Samba] Joining Windows 10 Domain Member to Samba AD/DC
Mark Foley
mfoley at novatec-inc.com
Sat Feb 10 21:57:33 UTC 2024
On Sat Feb 10 15:27:50 2024 Peter Milesson via samba <samba at lists.samba.org> wrote:
>
> 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?
Nothing in the logfile (logdir /var/log/chrony), nothing in syslog. The only
thing is messages is start-up logs.
This might be my next step to build chrony from sources. I too got mine from the
distro repo.
> Are there multiple interfaces on your DC? In that case, chrony may be
> listening on the wrong one?
Nope, just eth0.
> Do chronyd.pid and chronyd.sock in /var/run/chrony exist?
Yup:
# ls -l /var/run/chrony
total 4
-rw-r--r-- 1 root root 5 2024-02-10 13:49 chronyd.pid
srwxr-xr-x 1 chrony chrony 0 2024-02-10 13:49 chronyd.sock=
> Does chrony respond to requests from linux boxes?
Yes. Below, 192.168.0.2 is the DC. 192.168.0.3 is a Linux machine:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:23:10.952184 IP 192.168.0.3.ntp > 192.168.0.2.ntp: NTPv4, Client, length 48
16:23:10.952945 IP 192.168.0.2.ntp > 192.168.0.3.ntp: NTPv4, Server, length 48
> Note that the parameter ntpsigndsocket /var/lib/samba/ntp_signd is not a
> file, but a directory. That is described in the Samba wiki.
Yes, I've read that. I have that set to being owned by chrony:
# ls -ld /var/lib/samba/ntp_signd
drwxr-x--- 2 root chrony 4096 2024-02-10 04:02 /var/lib/samba/ntp_signd/
> 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
> 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
> 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
> Key id: 1828978688
> Authentication: f4a4d5849bfbc23d74e636aff69bc27d
Yes, clearly your chrony is replying to the query from your 182.16.0.9. Sadly,
mine is not and I currently have no idea why.
On the upside - at least I know *why* it's not working. Now to figure out how to
fix it!
--Mark
More information about the samba
mailing list