Samba4 domain controller not syncing time on domain workstations

I'm having a few odd problems with my Samba4 domain controller. One issue is: how can I verify that the domain Windows workstations are getting their time updated from the domain controller? In fact, today one of the workstations is set to January 4 2003, 7:28AM whereas the real date/time is April 6, 2015 10:28am. Obviously this workstations in not getting its time updated. How can I insure workstations get their time setting from the domain controller?
LVL 1
jmarkfoleyAsked:
Who is Participating?
 
jmarkfoleyAuthor Commented:
OK, I've confirmed on a different workstation, doing:

w32tm /config /manualpeerlist:mail,0x8 /syncfromflags:MANUAL
 w32tm /config /update

and nothing else does cause the workstation time to get updated. And, on the server, enabling ICMP.

The explanation give by https://www.meinbergglobal.com/english/info/ntp-w32time.htm is
Some w32time versions are unable to query time from NTP servers

Especially those coming with Windows XP or Windows Server 2003, may be (by default) unable to query the time from some NTP servers. Depending on the type of the Windows PC (e.g. standalone server or domain controller), NTP servers may not respond to the type of queries sent by w32time. w32time sends namely symmetric active instead of client mode packets to a NTP server. This problem has not been observed with the w32time version which has been shipped with Windows 2000, only with later versions.  ...
The flag "0x8" forces w32time not to send "symmetric active" packets but normal "client" requests which the NTP server replies to as usual.
Even though ntp is not part of Samba, this is something the Samba4 team need to look at since time between the AC/DC and client workstations need to be synchronized for AC/DC functions to work properly. Maybe I should send them a message.

I think this is resolved. I'll leave it open a bit longer in case you have any final thoughts.
0
 
arnoldCommented:
Hi Mark,

One way you can use DHCP options to set the time servers.

Certain deviations can not be handled by auto-update, the one you have might either have had its clock set by other means or if it is not a new system, the battery on the MB might be .,.....
0
 
compdigit44Commented:
Have to read the following article on setting up time sync on Samba 4 DC's?

https://wiki.samba.org/index.php/Time_Synchronisation
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
jmarkfoleyAuthor Commented:
I verified my settings with compdigit44's link and restarted ntpd. Still not sure how to tell if ntpd was compile with „--enable-ntp-signd. Is there some way to know that? I have:

drwxr-x--- 2 root root 4096 2015-04-02 22:16 /var/lib/samba/ntp_signd/
srwxrwxrwx 1 root root 0 2015-04-02 22:16 /var/lib/samba/ntp_signd/socket=

Which is fairly recent, but 7 days ago. Clearly not getting updated when ntpd restarts (but maybe when samba starts?)

I ran a few tests shown on https://lists.samba.org/archive/samba/2013-August/174831.html. On the Windows computer I can run:
C:\Users\Administrator>w32tm /monitor
mail.hprs.local *** PDC ***[192.168.0.2:123]:
    ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    NTP: +0.0000000s offset from mail.hprs.local
        RefID: (unknown) [0x00017F7F]
        Stratum: 11

Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.

Open in new window

which seems to imply it is getting time from mail.hprs.local (which is the DC/AD). But then ...
C:\Users\Administrator>w32tm /resync /rediscover
Sending resync command to local computer
The computer did not resync because no time data was available.

Open in new window

Implies otherwise.

Not really sure what these tell me:
C:\Users\Administrator>w32tm /config /syncfromflags:DOMHIER /update
The command completed successfully.

C:\Users\Administrator>w32tm /query /source
Local CMOS Clock

Open in new window

Bottom line: still not sure if Windows clients are getting time updated by DC. Is there a way to know?
0
 
jmarkfoleyAuthor Commented:
more info: According to that website I reference,
You can verify the configuration with "w32tm /query /configuration" and look for the "Type" to be NT5DS. This means it's using AD.
My results:
C:\Users\Administrator>w32tm /query /configuration
[Configuration]

EventLogFlags: 2 (Local)
AnnounceFlags: 10 (Local)
TimeJumpAuditOffset: 28800 (Local)
MinPollInterval: 10 (Local)
MaxPollInterval: 15 (Local)
MaxNegPhaseCorrection: 4294967295 (Local)
MaxPosPhaseCorrection: 4294967295 (Local)
MaxAllowedPhaseOffset: 300 (Local)

FrequencyCorrectRate: 4 (Local)
PollAdjustFactor: 5 (Local)
LargePhaseOffset: 50000000 (Local)
SpikeWatchPeriod: 900 (Local)
LocalClockDispersion: 10 (Local)
HoldPeriod: 5 (Local)
PhaseCorrectRate: 1 (Local)
UpdateInterval: 30000 (Local)


[TimeProviders]

NtpClient (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
CrossSiteSyncFlags: 2 (Local)
AllowNonstandardModeCombinations: 1 (Local)
ResolvePeerBackoffMinutes: 15 (Local)
ResolvePeerBackoffMaxTimes: 7 (Local)
CompatibilityFlags: 2147483648 (Local)
EventLogFlags: 1 (Local)
LargeSampleSkew: 3 (Local)
SpecialPollInterval: 3600 (Local)
Type: NT5DS (Local)

VMICTimeProvider (Local)
DllName: C:\Windows\System32\vmictimeprovider.dll (Local)
Enabled: 1 (Local)
InputProvider: 1 (Local)
NtpServer (Local)
DllName: C:\Windows\system32\w32time.dll (Local)
Enabled: 0 (Local)
InputProvider: 0 (Local)

Open in new window

Line 37 shows "Type: NT5DS (Local)". So, is it working? The "Local" modifier is a bit confusing -- what does "Local" mean attached to virtually every line?
0
 
arnoldCommented:
Usually you can look for w32tm system/application log entry indicating whether it sync up and with what system or if there was an error.

Try the w32tm /query.
You need to see what

ps -ef |grep ntpd
lsof -p <ntpd PID from above>
See if there is UDP port reflected there. And is not bound to 127.0.01: but shows up as * or 0.0.0.0
Make sure if you have iptables/firewall on the slackware box, that the port is open for lan queries.

Look at ntpd command in an effort to query your own ntpd to see the response if it responds.
0
 
jmarkfoleyAuthor Commented:
Try the w32tm /query. You need to see what
Not sure if you finished your sentence in that line ...

Below are the results of your suggested lsof. There is UDP *:ntp at line 22.
> ps -ef | grep ntpd
root     14608     1  0 Apr08 ?        00:00:01 /usr/sbin/ntpd -g -p /var/run/ntpd.pid
root     23365 14264  0 17:23 pts/1    00:00:00 grep ntpd
1 17:23:33 root@mail:~/spam
> lsof -p 14608
COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF     NODE NAME
ntpd    14608 root  cwd    DIR                9,0     4096        2 /
ntpd    14608 root  rtd    DIR                9,0     4096        2 /
ntpd    14608 root  txt    REG                9,0   550792 81818524 /usr/sbin/ntpd
ntpd    14608 root  mem    REG                9,0   110193 18612398 /lib64/libresolv-2.17.so
ntpd    14608 root  mem    REG                9,0    27146 18612394 /lib64/libnss_dns-2.17.so
ntpd    14608 root  mem    REG                9,0    61626 18612395 /lib64/libnss_files-2.17.so
ntpd    14608 root  mem    REG                9,0    17512 18612230 /lib64/libattr.so.1.1.0
ntpd    14608 root  mem    REG                9,0  2098910 18612403 /lib64/libc-2.17.so
ntpd    14608 root  mem    REG                9,0    20216 18612226 /lib64/libcap.so.2.22
ntpd    14608 root  mem    REG                9,0  1125896 18612391 /lib64/libm-2.17.so
ntpd    14608 root  mem    REG                9,0   171470 18612428 /lib64/ld-2.17.so
ntpd    14608 root    0u   CHR                1,3      0t0     1029 /dev/null
ntpd    14608 root    1u   CHR                1,3      0t0     1029 /dev/null
ntpd    14608 root    2u   CHR                1,3      0t0     1029 /dev/null
ntpd    14608 root    3u  unix 0xffff880108bd2700      0t0 15039959 socket
ntpd    14608 root   16u  IPv4           15039249      0t0      UDP *:ntp
ntpd    14608 root   17u  IPv6           15039250      0t0      UDP *:ntp
ntpd    14608 root   18u  IPv4           15039256      0t0      UDP localhost:ntp
ntpd    14608 root   19u  IPv4           15039257      0t0      UDP mail.ohprs.org:ntp
ntpd    14608 root   20u  IPv4           15039258      0t0      UDP mail.hprs.local:ntp
ntpd    14608 root   21u  IPv6           15039259      0t0      UDP [::1]:ntp
ntpd    14608 root   22u  IPv6           15039260      0t0      UDP [fe80::feaa:14ff:fe75:8d53]:ntp
ntpd    14608 root   23u  IPv6           15039261      0t0      UDP [fe80::feaa:14ff:fe75:8d51]:ntp
ntpd    14608 root   24u  sock                0,7      0t0 15039262 can't identify protocol

Open in new window

Make sure if you have iptables/firewall on the slackware box, that the port is open for lan queries.
All LAN ports are open.
Look at ntpd command in an effort to query your own ntpd to see the response if it responds.
Not sure I understand. Are you saying to query ntpd from self? Other clients are Windows.
0
 
jmarkfoleyAuthor Commented:
Found an interesting (maybe too old) link here: https://www.meinbergglobal.com/english/info/ntp-w32time.htm.

I'm pretty sure Windows clients are not using the DC. Note that in the w32tm /resync below, it is sending the command to local host:
C:\Users\Administrator>w32tm /resync
Sending resync command to local computer
The computer did not resync because no time data was available.

Open in new window

And nothing shows for NTP in the DC /var/log/messages of syslog. However `w32tm /monitor` does show (my post ID: 40714168, above):

mail.hprs.local *** PDC ***[192.168.0.2:123]:
    ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms
    NTP: +0.0000000s offset from mail.hprs.local

So it does appear the this workstation knows about the NTP server. I'm confused, but Windows tends to do that to me!
0
 
compdigit44Commented:
How many clients do you have? You could configure this in the registry on the clients
0
 
jmarkfoleyAuthor Commented:
How many clients do you have?
10
You could configure this in the registry on the clients
How?
0
 
arnoldCommented:
I might have driffted to a another thought as an alternative to troubleshoot the matter at hand

The lsof pointed out the your server is listening and
The non reply message suggests that:
1) either the request is not received on the NTP server
Or
2) no response is sent because the ntpd server is restricted such that the LAN is not seen as valid source of requests.

Try using tcpdump on your mail side and then trigger the w32tm /resync
What you are looking for is a packet comming and a response going out (line entrys)
tcpdump -i <interface that has the IP> port ntp
(Another option to monitor what the ntpd is actually doing, you can use the combination of ps -ef | grep ntpd to get the PID and then use strace -f -p <ntpd PID> while monitoring the network traffic with tcpdump)

The -f to strace tells it to follow the -p process listed.  I.e. Ntpd gets a connection and may spawn a new process to respond or a separate thread to respond, the -f makes your display follow whetever is began to handle...........

If you see the incoming, but not see a response.
Double check your NTPd.conf file to see whether you placed any restrictions there.
0
 
jmarkfoleyAuthor Commented:
the tcpdump is below. All workstations do appear to be talking to the server. However, when I did the `w32tm /resync` from the test workstation (COMMON) at 11:26:06 (line 28), I still got the same "The computer did not resync because no time data was available message." I'll have to wait until after business hours to try this on some of the other workstations.

The w32tm /monitor, on the test workstation does show "NTP: +0.0000000s offset from mail.hprs.local". Despite what the /sync results say, it seems like it must be updating to have a zero offset, right?

Well no, I set the workstation's time to 2 min less than the correct time. The w32tm /monitor still showed zero offset. I ran w32tm /sync, no change to 2minute lag. I let the workstation request an update (I watched the tcpdump to see when it did it on its own), no change.

Conclusion: The workstations are requesting ntp updates from the server. The server is responding, but no update it actually taking place on the workstation.

Why?
> tcpdump -i eth1 port ntp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
11:17:39.740318 IP MIKE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:17:39.740377 IP mail.hprs.local.ntp > MIKE.hprs.local.ntp: NTPv3, Server, length 52
11:17:45.574175 IP CHARMAINE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:17:45.574235 IP mail.hprs.local.ntp > CHARMAINE.hprs.local.ntp: NTPv3, Server, length 52
11:18:43.746690 IP MIKE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:18:43.746746 IP mail.hprs.local.ntp > MIKE.hprs.local.ntp: NTPv3, Server, length 52
11:18:46.718291 IP server.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:18:46.718352 IP mail.hprs.local.ntp > server.hprs.local.ntp: NTPv3, Server, length 52
11:19:06.349388 IP HOLLY.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:19:06.349448 IP mail.hprs.local.ntp > HOLLY.hprs.local.ntp: NTPv3, Server, length 52
11:19:15.757261 IP MIKE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:19:15.757309 IP mail.hprs.local.ntp > MIKE.hprs.local.ntp: NTPv3, Server, length 52
11:20:10.053560 IP DORIS.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:20:10.053625 IP mail.hprs.local.ntp > DORIS.hprs.local.ntp: NTPv3, Server, length 52
11:22:43.168067 IP MARK.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:22:43.168127 IP mail.hprs.local.ntp > MARK.hprs.local.ntp: NTPv3, Server, length 52
11:22:59.914197 IP viao.hprs.local.ntp > ntp.southwestitsolutions.net.ntp: NTPv4, Client, length 48
11:22:59.971172 IP ntp.southwestitsolutions.net.ntp > viao.hprs.local.ntp: NTPv4, Server, length 48
11:23:02.727050 IP server.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:23:02.727110 IP mail.hprs.local.ntp > server.hprs.local.ntp: NTPv3, Server, length 52
11:24:26.062538 IP DORIS.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:24:26.062605 IP mail.hprs.local.ntp > DORIS.hprs.local.ntp: NTPv3, Server, length 52
11:25:10.731389 IP server.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:25:10.731450 IP mail.hprs.local.ntp > server.hprs.local.ntp: NTPv3, Server, length 52
11:26:06.760943 IP COMMON.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:06.761003 IP mail.hprs.local.ntp > COMMON.hprs.local.ntp: NTPv3, Server, length 52
11:26:14.733563 IP server.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:14.733623 IP mail.hprs.local.ntp > server.hprs.local.ntp: NTPv3, Server, length 52
11:26:17.570437 IP CHARMAINE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:17.570498 IP mail.hprs.local.ntp > CHARMAINE.hprs.local.ntp: NTPv3, Server, length 52
11:26:26.681563 IP DENNIS.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:26.681623 IP mail.hprs.local.ntp > DENNIS.hprs.local.ntp: NTPv3, Server, length 52
11:26:34.065422 IP DORIS.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:34.065482 IP mail.hprs.local.ntp > DORIS.hprs.local.ntp: NTPv3, Server, length 52
11:26:46.734667 IP server.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:26:46.734727 IP mail.hprs.local.ntp > server.hprs.local.ntp: NTPv3, Server, length 52
11:27:38.074298 IP DORIS.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
:
11:33:10.913865 IP viao.hprs.local.ntp > mail.hprs.local.ntp: NTPv4, Client, length 48
11:33:10.913926 IP mail.hprs.local.ntp > viao.hprs.local.ntp: NTPv4, Server, length 48
:
11:33:21.738042 IP RENEE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:33:21.738101 IP mail.hprs.local.ntp > RENEE.hprs.local.ntp: NTPv3, Server, length 52
11:33:45.582790 IP CHARMAINE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:33:45.582850 IP mail.hprs.local.ntp > CHARMAINE.hprs.local.ntp: NTPv3, Server, length 52
11:33:55.809107 IP BETH.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:33:55.809168 IP mail.hprs.local.ntp > BETH.hprs.local.ntp: NTPv3, Server, length 52
11:34:02.356245 IP HOLLY.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:34:02.356305 IP mail.hprs.local.ntp > HOLLY.hprs.local.ntp: NTPv3, Server, length 52
11:34:15.763881 IP MIKE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:34:15.763940 IP mail.hprs.local.ntp > MIKE.hprs.local.ntp: NTPv3, Server, length 52
11:34:17.593185 IP CHARMAINE.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:34:17.593237 IP mail.hprs.local.ntp > CHARMAINE.hprs.local.ntp: NTPv3, Server, length 52
11:34:38.778864 IP COMMON.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
11:34:38.778921 IP mail.hprs.local.ntp > COMMON.hprs.local.ntp: NTPv3, Server, length 52

Open in new window

0
 
arnoldCommented:
Mark,

I am not in position to alter the AD workstations to TIME SYNC with a Linux box.  I did however configured one using net time /setsntp: to a linux box, and it did sync through the normal process, while telling it to sync auto check with the DC (windows in this case).

not sure whether or what is interfering with your attempt.
0
 
jmarkfoleyAuthor Commented:
I tried your `strace -f -p`. I get a continuous stream of the following messages:
select(25, [16 17 18 19 20 21 22 23 24], NULL, NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = -1 EINTR (Interrupted system call)

Open in new window

I also tried the `net time ... /set` command and it worked:
C:\Users\Administrator>net time /DOMAIN:hprs.local /querysntp
Current time at \\mail.hprs.local is 4/15/2015 12:31:04 AM

The command completed successfully.


C:\Users\Administrator>net time /DOMAIN:hprs.local /querysntp /set
Current time at \\mail.hprs.local is 4/15/2015 12:32:17 AM

The current local clock is 4/15/2015 12:30:25 AM
Do you want to set the local computer's time to match the
time at \\mail.hprs.local? (Y/N) [Y]: Y
The command completed successfully.

Open in new window

So, given all that, why doesn't NTP work? It is definitely not working (2 minute lag I set on test workstation persisted from 4/10 when I set it until just now). This despite tcpdump showing the workstation requesting the time and the server responding. Any idea?
0
 
jmarkfoleyAuthor Commented:
Per the website https://www.meinbergglobal.com/english/info/ntp-w32time.htm. I tried the commands shown below. According the the link, "The flag "0x8" forces w32time not to send "symmetric active" packets but normal "client" requests which the NTP server replies to as usual." I first set the local time to 2 minutes behind the DC time.
C:\Users\Administrator>w32tm /config /manualpeerlist:mail,0x8 /syncfromflags:MANUAL
The command completed successfully.

C:\Users\Administrator>w32tm /config /update
The command completed successfully.

C:\Users\Administrator>net time /DOMAIN:hprs.local /querysntp
Current time at \\mail.hprs.local is 4/15/2015 12:49:00 AM

The command completed successfully.

C:\Users\Administrator>w32tm /resync
Sending resync command to local computer
The command completed successfully.

Open in new window

Nothing. Time is still 2 minutes behind. the resync shows "Sending resync command to local computer." Why is is using local computer instead of the DC? Is there a setting somewhere?

I'm stuck and out of ideas. Anyone know what's going on?
0
 
arnoldCommented:
Unfortunately, no.

What about w32tm events in system event log, does it reflect anything?
0
 
jmarkfoleyAuthor Commented:
Good suggestion! I see 2 types of warnings, one in which the "peer [mail.ohprs.local] is unreachable" (event24 image), and the other whose 'details' say, "The requested name is valid, but no data of the requested type was found (0x80027AFC)" (event131 image). There seems to be 3-5 '131' events for every '24' event.

The last event is from 4/14 11:43PM, before I did that `w32tm /config /manualpeerlist:mail,0x8 ...` command. I have no events logged since then at all. I wonder if that messed things up even further. How would I undo that? If I've messed up this workstations I can try on another.

Otherwise, do these events tell you anything? (see attached images)
event24.jpg
event131.jpg
0
 
arnoldCommented:
Does your Samba4 DC/AD have both IPV4 and ipv6 enabled? Just trying to see whether the issue is that the request if ipv6 is being sent using the ipv6 address, but ntpd is not bound to the ipv6.

Search for the w32tm points to a possible issue with the registry/..... on some links.

The error could be the consequence of the inability to resolve the name you specified as the timesource. i.e. mail might not be determinable as x.x.x.x.  Try to make sure the registry entry for the PDC peer is the full name of your server either mail.ohprs.local or before you try this approach, make sure the TCP/IP DNS settings/advanced include the search domain as the local AD domain.
0
 
jmarkfoleyAuthor Commented:
Does your Samba4 DC/AD have both IPV4 and ipv6 enabled?
If you look at the lsof results in my posting ID: 40715975, April 9th, you can see that both ipv4 and ipv6 are enabled.

Actually, let's wait on further diagnosis. It might be working. Just for the heck of it I turned on IMCP on the server:
iptables -A INPUT -p icmp --icmp-type 8 -s 192.168.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Open in new window

Shortly thereafter I noticed the that the time was correct on the workstation. I then set the time back 2 minutes again (at about the same time as my last post) and now it is back to correct!

I had this idea because the `w32tm /monitor` command was showing "ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms". I made the suppositional leap that if the workstation couldn't ping the NTP host it might not even try syncing (although the tcpdump indicates that it *is* making NTP requests). After enabling IMCP I got:
C:\Users\Administrator>w32tm /monitor
mail.hprs.local *** PDC ***[192.168.0.2:123]:
    ICMP: 0ms delay
    NTP: +0.0000000s offset from mail.hprs.local
        RefID: ns.tx.primate.net [72.249.38.88]
        Stratum: 3

Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.

Open in new window

which now shows a ICMP response.

I'm going to set the date back again on this workstation and also on another workstation after hours and see what happens.
0
 
arnoldCommented:
..
Seems w32tm tests to see if something is there on the IP to which the server is set and only then sends out the time sync request.

Great to hear it is working.
0
 
jmarkfoleyAuthor Commented:
Well, let's *hope* it's working. It did sync my time on the test workstation. In about 1/2 hour I will try on a different workstation.

Seems odd that it is requesting NTP from the server anyway (ref tcpdump in post ID: 40717302), then discards the response.
0
 
arnoldCommented:
If ping (icmp) was the impediment for the test station's sync, it should be set for all others.

Your ntp.conf on mail, should include external server with which it will synchronize if not there already.
0
 
jmarkfoleyAuthor Commented:
Nope, it's not working. I may have to try that `w32tm /config /manualpeerlist:mail,0x8 ...` on this workstation and see if that makes a difference. A couple of curious things ... here are some selected messages from my tcpdump:
2015-04-15 20:51:34.391851 IP COMMON.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 48
:
2015-04-15 21:10:03.493564 IP BETH.hprs.local.ntp > mail.hprs.local.ntp: NTPv3, Client, length 68
2015-04-15 21:10:03.493624 IP mail.hprs.local.ntp > BETH.hprs.local.ntp: NTPv3, Server, length 52
2015-04-15 21:10:17.920162 IP viao.hprs.local.ntp > mail.hprs.local.ntp: NTPv4, Client, length 48
2015-04-15 21:10:17.920222 IP mail.hprs.local.ntp > viao.hprs.local.ntp: NTPv4, Server, length 48
2015-04-15 21:11:22.895412 IP BETH.hprs.local.61518 > 23.99.222.162.ntp: NTPv1, Client, length 48

Open in new window

The machine that now works is COMMON. The new test workstation is BETH. Many, but not all, of the BETH entries have a number appended to the hostname instead of .ntp, e.g. 61518. No other workstations show this; they all have .ntp. Any idea on that? Also, those with the number appended have "NTPv1" whereas all the rest of the workstations, including COMMON have "NTPv3".

Does this mean anything to you?
0
 
arnoldCommented:
61518 is a port of the process generating an NTP request to an external source.

When you use a hostname and not an FQDN Beth might resolve mail to your external domain versus to the internal IP.
Double check whether the 23.99 is your IP or .........

The samba4 ADDC setup is rather "recent" and perhaps not all the kinks have been identified/resolved.
0
 
jmarkfoleyAuthor Commented:
Double check whether the 23.99 is your IP or .........
Good eye! I didn't even notice that! No, 23.99.222.162 is not our IP. A quick whois shows that it belongs to Microsoft. So, a) why would the Workstation make an NTP request to a Microsoft server, and b) why is it showing up on the DC's tcpdump?

Possible answer to a) the 23.99.222.162 host is hard-coded in some registry entry on the workstation? But `w32tim /monitor` show my mail.hprs.local PDC ...? And I guess I didn't include this line in my listing, but apparently 23.99.222.162 is answering, but with NTPv3 and the time *still* doesn't get set right!
2015-04-15 22:47:25.769549 IP 23.99.222.162.ntp > BETH.hprs.local.54974: NTPv3, Server, length 48

Open in new window


Possible answer to b) perhaps it shows up on the DC's tcpdump because traffic is ip-forwarded from the LAN interface eth1 to the Internet interface on eth0?

This all brings up another interesting observation. Every so often a Linux workstation, which has mail.hprs.local configured as the preferred ntp server,  makes a request to southwestitsolutions.net.
2015-04-15 22:41:00.918614 IP viao.hprs.local.ntp > ntp.southwestitsolutions.net.ntp: NTPv4, Client, length 48
2015-04-15 22:41:00.977590 IP ntp.southwestitsolutions.net.ntp > viao.hprs.local.ntp: NTPv4, Server, length 48

Open in new window

Is this possibly because mail.hprs.local doesn't answer quick enough so it tries someone else in the pool? ntp.southwestitsolutions.net is 108.166.189.70 and is the next one in the ntpq list:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.0.2     72.249.38.88     3 u  669 1024  377    0.613   -0.529   1.088
+108.166.189.70  67.18.187.111    3 u  393 1024  377   58.582   -3.961   2.664
 127.127.1.0     .LOCL.          10 l   7d   64    0    0.000    0.000   0.000

Open in new window

Your thoughts on all the above would be appreciated.

Anyway, none of this seems likely to solve my current problem. My next step is to set the Microsoft Time service to automatic -- which I did for the working workstation. I'll let that run overnight and see if anything happens.
The samba4 ADDC setup is rather "recent" and perhaps not all the kinks have been identified/resolved.
Amen! Linux is generally robust and this will certainly get better. I just hate looking forward to "upgrading".
0
 
arnoldCommented:
The 23 is possibly time.windows.com?

Double heck whether the IP to which this external name points is not your external/public IP which has the ISP who has not updated the reverse lookup on the IP when they reallocated the IP from southwestitsolution to you.

What else is in the ntp.conf server list, it might be part of the ntp.org pool.
0
 
jmarkfoleyAuthor Commented:
What else is in the ntp.conf server list, it might be part of the ntp.org pool.
Yes, southwestitsolutions is part of the ntp.org.pool, certainly. 108.166.189.70 (listed in ntpq -np) is their IP. I think I won't worry about this one, probably normal.

Setting the 'Windows time' service to auto didn't help, but doing:

w32tm /config /manualpeerlist:mail,0x8 /syncfromflags:MANUAL
w32tm /config /update

Did the trick again! Note that it didn't work without doing the /update command.

I've hacked around on this workstation too much, so to get the final answer I'm going to try another workstation and only do these two command, no setting of services, etc. Might as well follow this to the conclusion and post something definitive here.

Another disquieting thing is that this 2nd workstation, BETH, seems to be syncing everywhere but with the mail.hprs.local domain controller, tcpdump: 23.99.222.162, 191.233.81.105 (?). Believe it or not, this latter IP is Microsoft ... in Brazil!

I'll be back!
0
 
jmarkfoleyAuthor Commented:
I figured out how to fix it.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.