Join Log in
Score:0
IT_User avatar Server

Using AD server as NTP server for non-windows hosts (rhel hosts). ntpstat continues to state unsynchronized but ntpdate works. Is this possible?

mx flag
IT_User

We currently have an AD server that we are using as a time source.

Our AD server is setup to host time locally and the windows domain clients sync up to this machine fine. We have the firewall disabled entirely on the hosts and there are no firewalls in between (all machines are on the same lan).

The ntp.conf looks like:

driftfile /var/lib/ntp/drift
restrict default
restrict 127.0.0.1
restrict ::1
server 192.168.1.10 iburst prefer
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
disable monitor
logfile /var/log/ntpd.log

I can stop the ntpd service and run:

ntpdate 192.168.1.10
16 Sep 15:12:18 ntpdate[297583]: adjust time server 192.168.1.10 offset 0.188928 sec

ntpdate -d 192.168.1.10
Looking for host 192.168.1.10 and service ntp
host found : 192.168.1.10
transmit(192.168.1.10)
receive(192.168.1.10)
transmit(192.168.1.10)
receive(192.168.1.10)
transmit(192.168.1.10)
receive(192.168.1.10)
transmit(192.168.1.10)
receive(192.168.1.10)
server 192.168.1.10, port 123
stratum 1, precision -23, leap 00, trust 000
refid [LOCL], delay 0.02579, dispersion 0.00081
transmitted 4, in filter 4
reference time:    e4eca422.d31c6b70  Wed, Sep 15 2021 16:56:02.824
originate timestamp: e4edde44.131c82ed  Thu, Sep 16 2021 15:16:20.074
transmit timestamp:  e4edde43.fbf54378  Thu, Sep 16 2021 15:16:19.984
filter delay:  0.02589  0.02580  0.02579  0.02582
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.092817 0.091966 0.091143 0.090334
         0.000000 0.000000 0.000000 0.000000
delay 0.02579, dispersion 0.00081
offset 0.091143
16 Sep 15:16:19 ntpdate[298357]: adjust time server 192.168.1.10 offset 0.091143 sec

.And the system syncs without issues. I proceed to start ntpd service and monitor using ntpq -p

The offset continues to grow every poll. I run ntpstat and it continues to report unsynchronized.

ntpstat
unsynchronised
 time server re-starting
  polling server every 8 s

Can linux hosts running ntp not connect to AD in this fashion? I read through Microsoft - how windows time works but failed to get a grasp on how non-windows domain systems connecting to an AD time server using NTP work with this.

301
0 + 0
ntp
vidarlo avatar
ar flag
vidarlo
What's the output of `ntpdate -d <server>`?
0
Reply
IT_User avatar
mx flag
IT_User
@vidarlo post updated to show results. It successfully steps the time.
0
Reply
IT_User avatar
mx flag
IT_User
@vidarlo apologies. Now the full output is there.
0
Reply
John Mahowald avatar
cn flag
John Mahowald
`ntpdate` doesn't tell you how your ntpd is working, although getting a timestamp does show a NTP server is running at that remote IP. Please edit to add details from running `chronyc tracking` or `ntpq -c "rv 0"` (these are what ntpstat parses).
0
Reply
John Mahowald avatar
cn flag
John Mahowald
AD DS does serve NTP by default, so you should be able to point NTP clients of any OS at the domain, `ad.example.net` or whatever.
0
Reply
Score:1
IT_User avatar Server
mx flag
IT_User

I managed to find the solution after digging in more.

Windows NTP Servers (at times for various reaons), will report a large root dispersion. This in turn causes chronyd/ntpd to ignore the ntp server fpr inaccurate data.

In order to resolve I needed to add:

tos maxdist 16

to my /etc/ntp.conf. After restarting the service everything began working.

This article helped gave a simple explanation.

https://access.redhat.com/solutions/4652771

I also stumbled upon this post regarding inadequate times which further helped troubleshoot and identify the issue.

Why is NTP considering my server inadequate?

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.