LFCE 70 🐧 Time Synchronization — Why It Matters - KandZ

⏱️ Estimated read: 12 min | |

Time synchronization is the process of keeping the system clock accurate and consistent across every machine in a network. On a single laptop, a few seconds of drift is an annoyance. On a server, it is a correctness problem. Authentication protocols reject tickets that are outside a narrow time window, log entries from different hosts cannot be correlated if their clocks disagree, and scheduled jobs may run twice or not at all when the clock jumps. The previous chapters covered services that depend on time—Kerberos, TLS certificates, and distributed applications—and this chapter explains why the clock beneath them must be trustworthy.

The LFCE exam objectives explicitly include implementing and configuring a time synchronization server . The protocol that makes this possible is the Network Time Protocol (NTP), which synchronizes a client’s clock to a hierarchy of reference clocks. NTP uses UDP port 123, and its algorithm measures the round-trip delay to a server and adjusts the local clock to compensate for the offset . The result is a clock that is accurate to within milliseconds on a local network, and to within tens of milliseconds across the internet.

Key point: A system clock that is not synchronized does not simply show the wrong time. It breaks the protocols that assume a shared notion of time. Kerberos refuses authentication when the client’s clock differs from the KDC’s by more than the configured tolerance . Log correlation becomes impossible when each host’s timestamps drift independently. NTP is the mechanism that prevents this drift, and it must be configured on every server that participates in a distributed system.

Why time synchronization exists

The authentication problem.

Kerberos tickets have a timestamp and a lifetime. The KDC checks the timestamp against its own clock, and if the difference exceeds the allowed skew, the authentication fails. A client with a clock that is five minutes fast cannot authenticate, even though its password is correct. The University of Oxford’s Kerberos documentation states that if clocks are not synchronized within a reasonable window, Kerberos reports fatal errors and refuses to function . The same principle applies to TLS certificate validation, which checks the certificate’s notBefore and notAfter dates against the local clock.

The log-correlation problem.

When an incident occurs, the administrator examines the logs from multiple servers to reconstruct the sequence of events. If the servers’ clocks are not synchronized, the timestamps cannot be ordered. An event that appears to have happened after another may have happened before it, and the reconstruction is wrong. Amazon’s EC2 documentation notes that timestamps in system logs play a crucial role in identifying when a problem occurred and the chronological order of events . The same reasoning applies to any multi-host deployment.

The distributed-transaction problem.

A transaction that spans multiple servers—a database write, a payment, a distributed lock—uses timestamps to determine ordering. If the servers’ clocks disagree, the ordering is inconsistent, and the transaction may be applied twice or not at all. The Azure documentation lists billing errors and authentication failures as consequences of clock drift between virtual machines . NTP is the mechanism that keeps the clocks close enough for the ordering to be meaningful.

a. The NTP hierarchy and the stratum model

NTP organizes time sources into a hierarchy of strata. A stratum 0 source is a reference clock—an atomic clock, a GPS receiver, or a radio clock. A stratum 1 server is directly synchronized to a stratum 0 source. A stratum 2 server is synchronized to a stratum 1 server, and so on. The stratum number is not a measure of quality; it is a measure of distance from the reference clock. A stratum 1 server is not necessarily more accurate than a stratum 2 server, but it is closer to the source.

# Check the current time synchronization status
timedatectl
# Output includes:
#   System time: ...
#   RTC time: ...
#   Time zone: ...
#   System clock synchronized: yes
#   NTP service: active

The timedatectl command shows whether the system clock is synchronized and whether the NTP service is active. On a system that uses systemd-timesyncd, the synchronization is handled by a lightweight client that implements SNTP, a simplified version of NTP. On a server that needs higher accuracy or the ability to serve time to other machines, the full ntpd or chronyd daemon is used.

b. The NTP algorithm and the four timestamps

NTP measures the offset between the local clock and the server’s clock using four timestamps. The client records the departure time of its request (T1), the server records the arrival time (T2) and the departure time of its reply (T3), and the client records the arrival time of the reply (T4). The offset is calculated as [(T2 - T1) + (T3 - T4)] / 2, and the round-trip delay as (T4 - T1) - (T3 - T2) .

# Query an NTP server with ntpdate (deprecated but useful for testing)
sudo ntpdate -q pool.ntp.org
# Output shows the server, the offset, and the delay

The -q flag queries the server without setting the clock. The output shows the offset in seconds, which is the difference between the local clock and the server’s clock. A positive offset means the local clock is behind; a negative offset means it is ahead. The ntpdate command is deprecated in favor of chronyd or timedatectl, but it remains a useful diagnostic tool.

The NTP algorithm does not simply set the clock to the server’s time. It gradually adjusts the clock’s frequency to compensate for drift, and it uses the round-trip delay to estimate the uncertainty of the measurement. The result is a clock that is not just corrected once, but continuously disciplined to stay close to the reference .

c. The daemons: chronyd, ntpd, and systemd-timesyncd

Linux has three common NTP implementations. chronyd is the default on RHEL and its derivatives, and it is designed for systems that are not always connected to the network. ntpd is the reference implementation, and it is available on Debian and Ubuntu. systemd-timesyncd is a lightweight SNTP client that is built into systemd, and it is the default on many desktop and minimal server installations.

# Check which NTP implementation is active
systemctl status chronyd    # RHEL default
systemctl status ntp        # Debian/Ubuntu with ntpd
systemctl status systemd-timesyncd  # systemd default

The chronyd daemon is configured in /etc/chrony.conf. The ntpd daemon is configured in /etc/ntp.conf. The systemd-timesyncd daemon is configured in /etc/systemd/timesyncd.conf. The choice of daemon depends on the distribution and the accuracy requirements. chronyd is the better choice for a server that may be offline for extended periods, because it can adjust the clock frequency without a network connection and it handles large clock jumps more gracefully than ntpd .

The firewall must permit UDP port 123 for NTP to function. A server that cannot reach its time source will drift, and the drift will accumulate until the clock is corrected manually or the daemon reconnects.

Complete Example Session

# ============================================
# PART 1: CHECK THE CURRENT TIME STATUS
# ============================================
timedatectl
# Output shows whether the clock is synchronized and whether NTP is active

# ============================================
# PART 2: CHECK THE ACTIVE NTP DAEMON
# ============================================
systemctl status chronyd 2>/dev/null || systemctl status ntp 2>/dev/null || systemctl status systemd-timesyncd

# ============================================
# PART 3: QUERY A TIME SERVER
# ============================================
sudo ntpdate -q pool.ntp.org
# Output shows the server, the offset, and the delay

# ============================================
# PART 4: CHECK THE CONFIGURED TIME SOURCES
# ============================================
# chronyd
grep -E "^server|^pool" /etc/chrony.conf
# ntpd
grep -E "^server|^pool" /etc/ntp.conf

# ============================================
# PART 5: ENABLE AND START THE DAEMON
# ============================================
sudo systemctl enable --now chronyd
# Or: sudo systemctl enable --now ntp

# ============================================
# PART 6: VERIFY THE SYNCHRONIZATION
# ============================================
chronyc tracking
# Output shows the reference ID, the stratum, the system time offset, and the frequency

# ============================================
# PART 7: LIST THE SOURCES
# ============================================
chronyc sources -v
# Output shows the servers, their stratum, and their reachability

# ============================================
# PART 8: CHECK THE FIREWALL
# ============================================
sudo firewall-cmd --list-services | grep ntp
# If ntp is not listed, add it:
# sudo firewall-cmd --permanent --add-service=ntp
# sudo firewall-cmd --reload

# ============================================
# PART 9: TEST A LARGE OFFSET
# ============================================
# Set the clock forward by 10 seconds (requires root)
# sudo date -s "$(date -d '+10 seconds')"
# chronyd will correct the offset gradually or with a step, depending on its configuration

# ============================================
# PART 10: VERIFY THE CORRECTION
# ============================================
sleep 5
chronyc tracking
# The system time offset should be reduced

The ten parts demonstrate the time synchronization workflow: checking the status, identifying the daemon, querying a server, inspecting the configuration, starting the service, verifying the synchronization, listing the sources, opening the firewall, testing an offset, and confirming the correction. The critical verification is Part 6: chronyc tracking shows the offset and the frequency, which confirm that the daemon is actively disciplining the clock.

Quick Reference

NTP Concepts

Concept	Meaning
Stratum	Distance from the reference clock
Offset	Difference between local clock and server clock
Delay	Round-trip time to the server
Reference ID	Identifier of the synchronization source
Frequency	Clock drift correction applied by the daemon

NTP Daemons

Daemon	Configuration	Default On
`chronyd`	`/etc/chrony.conf`	RHEL, Rocky, Fedora
`ntpd`	`/etc/ntp.conf`	Debian, Ubuntu (optional)
`systemd-timesyncd`	`/etc/systemd/timesyncd.conf`	systemd systems

Verification Commands

Command	Purpose
`timedatectl`	Show clock and NTP status
`chronyc tracking`	Show offset and frequency
`chronyc sources -v`	List time sources
`ntpdate -q <server>`	Query a server without setting the clock
`systemctl status <daemon>`	Check the daemon state

Firewall

Protocol	Port
NTP	UDP 123

Best Practices

✅ Do This:

# Use a pool of time servers
pool pool.ntp.org iburst                                       # ✅

# Verify the synchronization status
chronyc tracking                                               # ✅

# Open the firewall for NTP
firewall-cmd --add-service=ntp                                 # ✅

# Use the distribution's default daemon
# chronyd on RHEL, timesyncd on minimal systems                 # ✅

# Check the sources
chronyc sources -v                                             # ✅

❌ Don’t Do This:

# Leave the clock unsynchronized on a server
# Kerberos, TLS, and logs depend on accurate time              # ❌

# Use a single time server
# A pool provides redundancy                                  # ❌

# Ignore the firewall
# NTP cannot reach the server, and the clock drifts            # ❌

# Set the clock manually and expect it to stay accurate
# Drift accumulates; a daemon is required                     # ❌

# Mix ntpdate and a running daemon
# The daemon may fight the manual adjustment                  # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Clock drifts	No NTP daemon running	Enable `chronyd` or `ntpd`
Kerberos authentication fails	Clock skew exceeds tolerance	Synchronize the clock
Logs cannot be correlated	Hosts have different times	Configure NTP on every host
NTP daemon cannot reach servers	Firewall blocks UDP 123	Open the NTP service
Large offset not corrected	Daemon configured to step only small offsets	Check `makestep` in `chrony.conf`

Real-World Examples

1. Check time status

timedatectl

2. Query a time server

ntpdate -q pool.ntp.org

3. Check chronyd tracking

chronyc tracking

4. List sources

chronyc sources -v

5. Configure a pool

pool pool.ntp.org iburst

6. Enable chronyd

systemctl enable --now chronyd

7. Open the firewall

firewall-cmd --permanent --add-service=ntp && firewall-cmd --reload

8. Check the NTP service status

systemctl status chronyd

9. Check the configured servers

grep ^server /etc/chrony.conf

10. Force a step correction

chronyc makestep

Visual

NTP Stratum Hierarchy

┌──────────────────────────────────────────────────────────────┐
│  STRATUM MEASURES DISTANCE FROM THE REFERENCE CLOCK          │
│                                                              │
│  Stratum 0: Reference clock (atomic, GPS, radio)             │
│       │                                                      │
│       ▼                                                      │
│  Stratum 1: Server directly attached to the reference clock  │
│       │                                                      │
│       ▼                                                      │
│  Stratum 2: Server synchronized to a stratum 1 server        │
│       │                                                      │
│       ▼                                                      │
│  Stratum 3: Server synchronized to a stratum 2 server        │
│       │                                                      │
│       ▼                                                      │
│  Client: Synchronized to any reachable server                │
│                                                              │
│  The stratum is a distance, not a quality rating.            │
└──────────────────────────────────────────────────────────────┘

The Four Timestamps

┌──────────────────────────────────────────────────────────────┐
│  NTP MEASURES OFFSET AND DELAY WITH FOUR TIMESTAMPS          │
│                                                              │
│  Client                                 Server               │
│  ┌─────────┐                           ┌─────────┐          │
│  │ T1      │──── request ─────────────▶│ T2      │          │
│  │         │                           │         │          │
│  │ T4      │◀─── reply ────────────────│ T3      │          │
│  └─────────┘                           └─────────┘          │
│                                                              │
│  Offset = [(T2 - T1) + (T3 - T4)] / 2                        │
│  Delay  = (T4 - T1) - (T3 - T2)                              │
│                                                              │
│  The offset is the clock difference.                         │
│  The delay is the round-trip time.                           │
└──────────────────────────────────────────────────────────────┘

Why Kerberos Needs Accurate Time

┌──────────────────────────────────────────────────────────────┐
│  KERBEROS REJECTS TICKETS WITH CLOCK SKEW                    │
│                                                              │
│  KDC clock: 12:00:00                                         │
│  Client clock: 12:05:00 (5 minutes fast)                     │
│       │                                                      │
│       ▼                                                      │
│  Client requests a ticket                                    │
│       │                                                      │
│       ▼                                                      │
│  KDC checks the timestamp against its own clock              │
│  The difference (5 minutes) exceeds the allowed skew         │
│       │                                                      │
│       ▼                                                      │
│  Authentication fails                                        │
│                                                              │
│  NTP keeps the client's clock within the tolerance.          │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Protocol	Network Time Protocol (NTP)
Port	UDP 123
Stratum	Distance from the reference clock
Offset	Difference between local and server clock
Delay	Round-trip time to the server
RHEL daemon	`chronyd`
Debian daemon	`ntpd` or `systemd-timesyncd`
chrony config	`/etc/chrony.conf`
ntp config	`/etc/ntp.conf`
Verification	`chronyc tracking`, `timedatectl`
Firewall	UDP 123

Key takeaways:

Unsynchronized clocks break authentication. Kerberos rejects tickets when the client’s clock differs from the KDC’s by more than the allowed skew. The failure is not a password error; it is a time error, and it is fixed by synchronizing the clock .
NTP uses four timestamps to measure offset and delay. The client records the request departure and reply arrival, and the server records the request arrival and reply departure. The offset is the clock difference, and the delay is the round-trip time .
The stratum is a distance, not a quality rating. A stratum 1 server is directly attached to a reference clock, and a stratum 2 server is synchronized to a stratum 1 server. The stratum number increases with each hop from the reference.
chronyd is the default on RHEL and its derivatives. It is designed for systems that may be offline for extended periods, and it handles large clock jumps more gracefully than ntpd. The configuration is in /etc/chrony.conf .
The firewall must permit UDP 123. A server that cannot reach its time source drifts, and the drift accumulates until the daemon reconnects or the clock is corrected manually.
chronyc tracking is the verification command. It shows the reference ID, the stratum, the system time offset, and the frequency. The offset should be small, and the frequency should be stable.

Remember: Time synchronization is not a convenience; it is a correctness requirement. Kerberos, TLS, log correlation, and distributed transactions all depend on a shared notion of time. NTP is the protocol that provides it, and chronyd or ntpd is the daemon that implements it. The stratum hierarchy organizes the sources, the four timestamps measure the offset, and the daemon disciplines the clock continuously. Configure a pool of servers, enable the daemon, open the firewall, and verify with chronyc tracking. A server with an unsynchronized clock is a server that will eventually fail in a way that is difficult to diagnose.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!