Peter Milesson
2024-Feb-10 09:35 UTC
[Samba] Joining Windows 10 Domain Member to Samba AD/DC
On 10.02.2024 8:52, Mark Foley via samba wrote:> 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 >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
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