Ubuntu 20.04 refuses to sync time with Windows AD, how to trouble shoot?

Question

I am trying to sync a Ubuntu 20.04 client to a Windows AD time server. But time will never sync. Here is what I know so far:

• Windows server is listening on port 123 for NTP, and replies to requests.
• I am using timedatectl. systemd-timesyncd.service is running.
• Tried to reboot the ubuntu client and AD server
• Make sure ufw was disabled, iptables does not appear to have any entries blocking anything, and its obvious its not as I can see from packet capture.
• Windows Time service appears to be running.
• The following output I found from trouble shooting:

$ journalctl -fu systemd-timesyncd.service
-- Logs begin at Tue 2022-08-16 10:38:00 EDT. --
Jan 11 16:25:51 server.my.domainsystemd-timesyncd[775]: Timed out waiting for reply from 10.200.0.54:123 (10.200.0.54).
Jan 11 16:26:02 server.my.domainsystemd-timesyncd[775]: Timed out waiting for reply from 10.200.0.54:123 (10.200.0.54).
Jan 11 16:27:22 server.my.domainsystemd[1]: Stopping Network Time Synchronization...
Jan 11 16:27:22 server.my.domainsystemd[1]: systemd-timesyncd.service: Succeeded.
Jan 11 16:27:22 server.my.domainsystemd[1]: Stopped Network Time Synchronization.
Jan 11 16:27:22 server.my.domainsystemd[1]: Starting Network Time Synchronization...
Jan 11 16:27:22 server.my.domainsystemd[1]: Started Network Time Synchronization.
Jan 11 16:29:52 server.my.domainsystemd-timesyncd[5926]: Network configuration changed, trying to establish connection.
Jan 11 16:30:05 server.my.domainsystemd-timesyncd[5926]: Network configuration changed, trying to establish connection.
Jan 11 16:32:04 server.my.domainsystemd-timesyncd[5926]: Network configuration changed, trying to establish connection.

$ timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=10.200.0.54
FallbackNTPServers=ntp.ubuntu.com
ServerName=10.200.0.54
ServerAddress=10.200.0.54
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=34min 8s
Frequency=0

$ timedatectl
               Local time: Wed 2023-01-11 16:34:14 EST
           Universal time: Wed 2023-01-11 21:34:14 UTC
                 RTC time: Wed 2023-01-11 21:34:14
                Time zone: America/New_York (EST, -0500)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Here is a comparison of response from an extenral NTP server on another host that is working, and the NTP server I am having issues with:

Here are Windows server ntp info (Sorry for screen shots but this is from a console I could not copy it all):

What am I missing? Why is the Windows Server not giving time properly?

EDIT: I deployed a new AD server just to test if time will work. And it does. I had to extend the root distance but it works. The AD in question still does not :(

EDIT2: OK I got it working, but only with an external peer list. Here are the steps I followed:

1. w32tm /config /manualpeerlist:time.windows.com,0x1 /syncfromflags:manual /reliable:yes /update
2. w32tm /config /syncfromflags:domhier /update
3. net stop w32time
4. net start w32time
5. Check TIMESERV is listed under Flags when running nltest /dsgetdc:your.domain /server:thehostnameofthedcyourdoingthisfrom
6. On linux host you must adjust your Root Distance I changed to "30" vi /etc/systemd/timesyncd.conf uncomment "RootDistance" and change to "30", save. Then run systemctl restart systemd-timesyncd.service

This is good news but not sure why CMOS local time does not work still..

Answer 1

Your domain controller is using the local CMOS clock as a source and is not synchronized and likely not advertising as a time server and thus the invalid data. You should start with confirming that the Hyper-V Time Synchronization box is unchecked for the integration services, and configure it with valid NTP servers.

You can enable Windows Time Service logging for additional information.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/turn-on-debug-logging-in-windows-time-service

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-for-traceability?tabs=257

Best practice for external NTP Server on Windows AD network

---

https://learn.microsoft.com/en-us/services-hub/health/remediation-steps-ad/configure-the-root-pdc-with-an-authoritative-time-source-and-avoid-widespread-time-skew

"In some scenarios, the PDC emulator gets its time from the BIOS clock. However, this approach has drawbacks. If the time and date is not set accurately in the PDC emulator BIOS, time and date settings will be incorrect across the domain. In addition, if the PDC emulator goes offline, domain members will be unable to synchronize time. A better approach is to configure the PDC emulator to synchronize time directly with an external time source. Alternatively, you can configure another device within your domain to synchronize time with an external time service, and then configure the PDC emulator to use your internal time server as the authoritative time source.

"Authoritative external time sources are Internet-facing services, typically maintained by governmental, scientific, or educational establishments that enable you to synchronize your system time using Network Time Protocol (NTP). For example, NIST provides time servers in various locations across the United States."

Suggested Actions

You can configure the Domain Controller holding the PDCE role to use an NTP Server to synchronize time, there are several approaches:

To configure time synchronization via command line, on the PDC emulator open administrative Command Prompt and use the following commands:

w32tm.exe /config /syncfromflags:manual /manualpeerlist:131.107.13.100,0x8 /reliable:yes /update

w32tm.exe /config /update

---

https://dirteam.com/sander/2019/07/18/managing-active-directory-time-synchronization-on-vmware-vsphere/

Recommendations

Disable time synchronization with the hypervisor host on the virtual Domain Controller holding the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role in the root domain and synchronize its time with a combination of:

DNS names of a reliable time source on the internet, like pool.ntp.org.
IP addresses of a reliable time source on the internet, like 131.211.8.244 and 5.79.108.34. (This make sure time synchronization occurs even when DNS is unavailable and minimizes the effect of DNS poisoning attacks.)
IP addresses of reliable time sources on the internal network, like GPS-based NTP appliances on the internal network. (This makes sure time synchronization occurs even when internet connectivity is unavailable).