Time is critical for AD infrastructure. DCs provide time (via NTP protocol) to all machines in the network. DCs must be configured as NTP servers. Other machines, such as file servers, will sync to them via systemd-timesyncd.

For DCs we will use Chrony, as it is simpler to use. The Debian 12 ntpsec server does not work properly.

The ntpsigndsocket allows Chrony to communicate with the Samba Kerberos service. This communication is necessary to securely sign time requests using GSS-TSIG (Generic Security Services - Transaction Signature), ensuring that time synchronization is authenticated and protected.

# Make sure NTP is not installed
apt-get remove ntp ntpstat python3-ntp ntpsec --purge
apt-get update && apt-get install chrony
 
mkdir /var/lib/samba/ntp_signd  # Directory may exist, don't worry if error
chown root:_chrony /var/lib/samba/ntp_signd/
chmod 750 /var/lib/samba/ntp_signd/

Edit `/etc/chrony/chrony.conf` and add at the end:

# IP address of this DC
bindcmdaddress 192.168.0.2

# Allow my network to query
allow 192.168.0.0/24

ntpsigndsocket /var/lib/samba/ntp_signd

Default Debian chrony config has a line similar to this:

# Use Debian vendor zone.
pool 2.debian.pool.ntp.org iburst

However if you want to update the list to your own servers, comment out that line and add something like this:

# The source, where we are receiving the time from
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst

Finally, reboot NTP to activate all changes:

systemctl restart chronyd

Peering NTP servers between Samba Domain Controllers (DCs) is generally a bad idea due to the critical role precise time synchronization plays in Active Directory (AD) environments. Samba DCs rely on Kerberos authentication and AD replication, both of which require time differences to stay within a 5-minute window to function correctly.

Configuring DCs to peer their NTP servers—where they bidirectionally sync time with each other—introduces significant risks. If one DC experiences clock drift or misconfiguration, it can propagate incorrect time to others, leading to cascading synchronization failures that disrupt authentication, replication, and domain operations.

Peering also creates complex dependencies, making troubleshooting difficult and increasing the likelihood of time skews that deviate from global UTC standards. Instead, best practice is to configure all DCs to sync with reliable external NTP servers (e.g., pool.ntp.org) or designate the PDC Emulator as the authoritative time source, ensuring consistent, accurate time across the domain without the pitfalls of peering.

Peering NTP servers between Samba DCs is only advisable in air-gapped environments with no external NTP access, where one DC has a reliable time source (e.g., GPS clock), and others peer with it to maintain local consistency. Even then, a client-server model is usually preferable.

See Chrony's manpage option `-x`:

This option disables the control of the system clock. Chronyd will not try to make any adjustments of the clock. It will assume the clock is free-running and still track its offset and frequency relative to the estimated true time. This option allows Chronyd to be started without the capability to adjust or set the system clock (e.g. in some containers), to operate as an NTP server.

Edit the service (this creates an override file `/etc/systemd/system/chrony.service.d/override.conf`):

systemctl edit chrony.service

And add:

[Unit]
ConditionCapability=

Also, add the following option `-x` to `/etc/default/chrony` so it looks like this:

DAEMON_OPTS="-F 1 -x"

This allows Chronyd to start and work properly in a container; however, it won’t actually manage the system clock (which is managed by the hypervisor host).

Restart the Chrony service:

systemctl restart chrony.service

Confirm NTP service is active:

timedatectl status

Example output:

               Local time: Sat 2023-09-16 13:36:08 CEST
           Universal time: Sat 2023-09-16 11:36:08 UTC
                 RTC time: Sat 2023-09-16 11:36:08
                 Time zone: Europe/Madrid (CEST, +0200)
  System clock synchronized: yes
              NTP service: active
              RTC in local TZ: no

Some tests to confirm NTP is working. Run all these tests on a domain-joined Windows machine.

Measure the time offset between the local system and the specified server `dc1.mad.caponato.es`. The following command collects five samples and displays only the offset values, which helps assess synchronization accuracy and detect delays.

You can try this with your other DCs as well:

w32tm /stripchart /computer:dc1.mad.caponato.es /dataonly /samples:5

Example output:

Tracking dc1 [192.168.0.2:123].
Collecting 5 samples.
The current time is 17/11/2023 12:08:48.
12:08:48, +00.0584404s
12:08:50, +00.0583222s
12:08:52, +00.0583822s
12:08:54, +00.0583711s
12:08:56, +00.0583450s

The `w32tm /query /status` command shows the current status of the Windows Time Service:

w32tm /query /status

Example output:

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - synced by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0357911s
Root Dispersion: 0.5098218s
ReferenceId: 0xC0A8000E (source IP: 192.168.0.14)
Last Successful Sync Time: 25/10/2023 10:13:00
Source: dc1.mad.caponato.es
Poll Interval: 15 (32768s)

The command `w32tm /monitor` displays the synchronization status of nearby domain controllers:

w32tm /monitor

Example output:

dc2.mad.caponato.es.[192.168.0.3:123]:
  ICMP: 0ms delay
  NTP: -0.0005589s offset from dc1.mad.caponato.es
      RefID: gomadr.hojmark.net [65.20.99.74]
      Stratum: 3

dc1.mad.caponato.es *** PDC ***[192.168.0.2:123]:
  ICMP: 0ms delay
  NTP: +0.0000000s offset from dc1.mad.caponato.es
      RefID: gomadr.hojmark.net [65.20.99.74]
      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.

This provides detailed information about the service’s operational parameters. Look for Type: NT5DS (Local) — this confirms that NTP is signed.

Since the Type is NT5DS, the system does not communicate with external NTP servers (like `time.windows.com`) but instead synchronizes with the domain controller. Time synchronization is signed and secured by Kerberos authentication.

w32tm /query /configuration

Look for this section:

NtpClient (Local)
...
Type: NT5DS (Local)

In case of persistent NTP issues, the best way to diagnose is using tcpdump on the DC.

Example of a correct NTP conversation:

tcpdump -v port 123 udp

Example output:

17:38:48.912484 IP (tos 0x0, ttl 128, id 12922, offset 0, flags [none], proto UDP (17), length 96)
PCSEC01.mad.caponato.es.ntp > dc2.mad.caponato.es.ntp: NTPv3, Client, length 68
  Leap indicator: (0), Stratum 5 (secondary reference), poll 10 (1024s), precision -23
  Root Delay: 0.032287, Root dispersion: 3.784896, Reference-ID: 0xc0a8000d
  Reference Timestamp: 3927626518.829402699 (2024-06-17T15:21:58Z)
  Originator Timestamp: 3927626504.901653134 (2024-06-17T15:21:44Z)
  Receive Timestamp: 3927626504.899602399 (2024-06-17T15:21:44Z)
  Transmit Timestamp: 3927627528.907404599 (2024-06-17T15:38:48Z)
  Originator - Receive Timestamp: -0.002050734
  Originator - Transmit Timestamp: +1024.005751465
  Key id: 805699584
  Authentication: 00000000000000000000000000000000

17:38:48.913407 IP (tos 0x0, ttl 64, id 64754, offset 0, flags [DF], proto UDP (17), length 96)
dc2.mad.caponato.es.ntp > PCSEC01.mad.caponato.es.ntp: NTPv3, Server, length 68
  Leap indicator: (0), Stratum 4 (secondary reference), poll 10 (1024s), precision -24
  Root Delay: 0.030212, Root dispersion: 0.001159, Reference-ID: 0xa29fc87b
  Reference Timestamp: 3927626832.614725473 (2024-06-17T15:27:12Z)
  Originator Timestamp: 3927627528.907404599 (2024-06-17T15:38:48Z)
  Receive Timestamp: 3927627528.912293049 (2024-06-17T15:38:48Z)
  Transmit Timestamp: 3927627528.912419205 (2024-06-17T15:38:48Z)
  Originator - Receive Timestamp: +0.004888449
  Originator - Transmit Timestamp: +0.005014606
  Key id: 805699584
  Authentication: 6f00cdb623536b5965a248829911b808

Note: I have been unable to reproduce this problem myself, but some users report that since Samba 4.17.x, time sync does not work unless this registry entry is set.

If this value is set to zero, time synchronization occurs without a signature. In small to medium-sized environments this may be acceptable, but in larger deployments it introduces a potential security risk.

Registry path:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Set:

SignatureAuthAllowed=0

See:

https://lists.samba.org/archive/samba/2025-January/250758.html

When a Windows PC boots with an incorrect hardware clock (CMOS/RTC), it can create a classic *chicken-and-egg* problem in Active Directory environments.

If the system time is too far off from the domain controllers’ time, Kerberos authentication will fail. This means the PC may not be able to:

• Apply Group Policy Objects (GPOs)
• Synchronize time via the domain hierarchy (NT5DS)
• Authenticate securely with the DCs

The result is a machine stuck using its own Local CMOS Clock, unable to correct itself because it cannot access the very resources required to fix the problem.

The way out of this loop is to bring the local clock back into reasonable sync (within ±5 minutes of the DCs). This can be done manually with the date and time commands in Windows CMD:

date 22-10-2025
time 08:55:00

Once the local time is close enough, Kerberos communication will succeed again. At that point, running:

w32tm /resync /force

will hopefully allow the PC to synchronize with its domain controller.

Finally, rebooting the system ensures that Windows writes the corrected system time back into the hardware CMOS/RTC clock:

shutdown /r /t 0

After the reboot, the machine will start with the correct hardware time, read GPOs successfully, and maintain proper synchronization with the domain controllers.

Caponato's Samba notebook — Start here or return to Main menu.