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, LPLuis, 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 in https://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 > > > > -- > > To unsubscribe from this list go to the following URL and read the > > instructions: https://lists.samba.org/mailman/options/samba > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
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