Kees van Vloten
2024-Feb-10 20:21 UTC
[Samba] Joining Windows 10 Domain Member to Samba AD/DC
On 10-02-2024 21:17, Mark Foley via samba wrote:> On Sat Feb 10 14:48:04 2024 Kees van Vloten 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 >>> >> You can check ntp on windows with: w32tm /monitor >> >> It should list one or more DCs as source >> >> - Kees. > Yes, I know. It doesn't. It lists either "Local CMOS Clock" or "Free-running > System Clock". > > --MarkDo you have a firewall enabled on Windows or on the DCs (or filtering network routers in between), perhaps?
On Sat Feb 10 15:21:24 2024 Kees van Vloten via samba <samba at lists.samba.org> wrote:> > On 10-02-2024 21:17, Mark Foley via samba wrote: > > On Sat Feb 10 14:48:04 2024 Kees van Vloten 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 > >>> > >> You can check ntp on windows with: w32tm /monitor > >> > >> It should list one or more DCs as source > >> > >> - Kees. > > Yes, I know. It doesn't. It lists either "Local CMOS Clock" or "Free-running > > System Clock". > > > > --Mark > Do you have a firewall enabled on Windows or on the DCs (or filtering > network routers in between), perhaps?No, I believe stripchart on Windows shows that it can contact the DC: 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 4:25:28 PM. 16:25:28, -00.0640562s 16:25:30, -00.0645102s 16:25:32, -00.0650520s 16:25:34, -00.0656132s 16:25:36, -00.0661244s striptchart's request packets do no include the ntp-signd Id and therefore the DC does reply (192.168.0.4 is a Windows domain member): 16:25:34.612852 IP (tos 0x0, ttl 128, id 21880, offset 0, flags [none], proto UDP (17), length 76) 192.168.0.4.59581 > mail.hprs.local.ntp: NTPv1, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 3916589134.677684699 (2024-02-10T21:25:34Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 3916589134.677684699 (2024-02-10T21:25:34Z) ---> No Key Id: in the request 16:25:34.613096 IP (tos 0x0, ttl 64, id 63901, offset 0, flags [DF], proto UDP (17), length 76) mail.hprs.local.ntp > 192.168.0.4.59581: NTPv1, Server, length 48 Leap indicator: (0), Stratum 3 (secondary reference), poll 0 (1s), precision -20 Root Delay: 0.065856, Root dispersion: 0.003448, Reference-ID: 0x68839baf Reference Timestamp: 3916589020.098304969 (2024-02-10T21:23:40Z) Originator Timestamp: 3916589134.677684699 (2024-02-10T21:25:34Z) Receive Timestamp: 3916589134.612477981 (2024-02-10T21:25:34Z) Transmit Timestamp: 3916589134.612684206 (2024-02-10T21:25:34Z) Originator - Receive Timestamp: -0.065206718 Originator - Transmit Timestamp: -0.065000493 --Mark