Peter Milesson
2024-Feb-09 17:02 UTC
[Samba] Joining Windows 10 Domain Member to Samba AD/DC
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
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, > > PeterYes, 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