What Is NTP? Clock Synchronization and Stratum

NTP (Network Time Protocol) is the protocol that takes the clock of every device on a network from one shared source and keeps them synchronized. Its job isn’t to make a device’s clock correct, it’s to make all the devices’ clocks the same as each other. The two sound identical; when a fault hits, the difference becomes very clear.

Every country produces its official time from one place. A national metrology institute runs a cesium atomic clock that produces the country’s official time and distributes it for free over the internet. Radio used to broadcast a time signal and everyone set their wristwatch to it; today you don’t set your phone’s clock at all, it follows the same chain upward. Only the distribution channel changed, the logic is the same. So why is a country’s official time produced from a single place? Not for accuracy, for agreement. If two institutions’ clocks drift five minutes apart, the appointment is missed, the bus is missed, the exam starts at the wrong moment.

In a corporate network the situation is exactly the same, and we’ll come back to this same official-time chain throughout the article. Below we’ll first see why a clock drifts on its own, then the stratum hierarchy that decides whose clock comes from whom, then move past the servers to the network-wide time architecture from the firewall to the camera. Then the three concrete costs of a drifting clock (authentication stopping, evidence value eroding, failing to produce proof in an audit) and the three traps seen most often in the field. If you have a system that isn’t keeping time right now, you can jump straight to the diagnosis order. This article is part of the monitoring and alerts guide, on the time-foundation side: correlatable logs and alerts start with agreeing clocks.

What Is NTP, and What Does It Do?

NTP is the protocol that compares a device’s clock against a reference source over the network and closes the gap between them, using UDP port 123. The device asks the other side “what’s the time,” works out the difference from the answer while accounting for the path delay, and adjusts its clock to that difference.

Why Does a Clock Drift on Its Own?

Inside every device is a small crystal oscillator counting the time, and that crystal never vibrates at exactly the expected rate. Because of manufacturing tolerance, ambient temperature and aging, each device runs a few seconds fast or slow per day. The drift isn’t even constant: of two switches of the same model, one runs ahead, the other behind.

Your mechanical wristwatch was the same. Nobody called it “broken,” it was wound and set once a month. The broken clock isn’t the wrong one, it’s the unadjusted one.

The numbers slip past you because they look small. A two-second daily drift becomes six minutes in six months, and that exact threshold triggers every one of the faults you’ll see later in this article. Nobody notices anything in a day; the problem shows up a year later, with a symptom that seems entirely unrelated.

Not the Correct Clock, the Common Clock

The real problem NTP solves isn’t accuracy, it’s commonality. If every device in a network were three minutes ahead at the same time, no fault would occur; it occurs only when one device’s clock drifts. That’s why official time exists too. Whether a country’s time is universally “correct” isn’t what matters to a citizen; that everyone uses the same time is. If the bus leaves at 14:30, both the driver and the passenger need to see the same 14:30.

The practical result: you don’t confirm clock synchronization by looking at the time on screen. The on-screen clock can look right while the device is four minutes off from its neighbor, and that’s a big enough gap to stop authentication. Confirmation is done with a command that measures the difference.

Stratum: Where Does the Clock Come From?

Stratum is the number that shows how many steps a time source sits from the reference, and NTP’s whole architecture is built on it. As the number shrinks you get closer to the source, as it grows you get farther away.

How Is the Chain Built? Stratum 0 to 3

Stratum 0 is the reference itself: an atomic clock or a GPS receiver. This layer doesn’t connect to the network directly, it feeds the server attached to it. That server becomes Stratum 1, the first distribution point on the network. A server taking time from it is Stratum 2, one taking from that is Stratum 3.

The official-time chain works exactly like this. A national metrology institute’s cesium atomic clock is the reference; the national time it distributes (from a server such as time.nist.gov in the US, or your own country’s authority) is at Stratum 1 and is free. When your own NTP server is fed from there it’s Stratum 2, and the devices it feeds are Stratum 3. You set your wristwatch not from the radio but from the office wall clock; the wall clock took its own time from higher up.

The international counterpart is the pool.ntp.org pool: a system of volunteer servers worldwide that returns different servers in turn over DNS. You use addresses from 0.pool.ntp.org to 3.pool.ntp.org, and there are regional subdomains for most countries.

An Organization Should Have One Time Source

An organization’s time source should be single, and this is less about accuracy than about consistency. When five different devices connect to five different external NTP addresses, they all technically get the correct time, but seconds-level differences remain between them, and when one source silently stops answering, the devices fed by it start drifting from the rest. And when the problem surfaces, no one remembers which device took time from whom.

The single-source rule has no exception, but it has a subtlety: one source doesn’t mean one server. Your internal NTP server can define more than one external address when it reaches out; NTP is designed to compare several sources and discard the inconsistent one. What’s centralized isn’t the number of external connections, it’s the distribution point inside the organization.

Seeing the Stratum on the Wire

The stratum and the offset above are usually met as abstractions. They aren’t abstract on the network: they’re specific fields in a packet. We captured one exchange against a lab NTP server (chrony on 192.168.1.15) to open it up. The capture was taken on the server itself, so both endpoints read 192.168.1.15, and the decode is tcpdump -vvv, trimmed to the NTP fields. The bad udp cksum note is an artifact of capturing on the sending host itself, not a fault.

The client’s request is a mode 3 (Client) packet. Almost everything in it is empty, only the Transmit Timestamp is set:

192.168.1.15.56382 > 192.168.1.15.123: [bad udp cksum 0x83b8 -> 0xf2f8!] NTPv4, Client, length 48
	Leap indicator:  (0), Stratum 0 (unspecified), poll 6 (64s), precision 32
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
	  Reference Timestamp:  0.000000000
	  Originator Timestamp: 0.000000000
	  Receive Timestamp:    0.000000000
	  Transmit Timestamp:   3001116363.307298355 (1995-02-07T03:26:03Z)
...

That transmit timestamp reads as a nonsensical 1995 date on purpose: chrony fills it with a random value rather than the real send time, as a spoofing defense. The server copies it back verbatim into the Originator field of its reply, so the client can confirm the answer belongs to its own request and reject anything that doesn’t echo the value it sent.

The reply is a mode 4 (Server) packet, and this time all four timestamps are set. Right after boot, before chrony had selected an upstream source, the server answered from its local fallback (local stratum 10 in the config), at Stratum 10 with the local-clock reference ID 0x7f7f0101:

192.168.1.15.123 > 192.168.1.15.56382: [bad udp cksum 0x83b8 -> 0x1ed3!] NTPv4, Server, length 48
	Leap indicator:  (0), Stratum 10 (secondary reference), poll 6 (64s), precision -25
	Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: 0x7f7f0101
	  Reference Timestamp:  3998837924.855081161 (2026-09-19T20:18:44Z)
	  Originator Timestamp: 3001116363.307298355 (1995-02-07T03:26:03Z)
	  Receive Timestamp:    3998837965.546286796 (2026-09-19T20:19:25Z)
	  Transmit Timestamp:   3998837965.547123000 (2026-09-19T20:19:25Z)
...

About two minutes later (20:21:46), once chrony had settled on an upstream, the same query drew a different answer: Stratum 3, with a reference ID (0xb9ff5fcf) that is the address of the upstream server it now follows:

192.168.1.15.123 > 192.168.1.15.42120: [bad udp cksum 0x83b8 -> 0x3485!] NTPv4, Server, length 48
	Leap indicator:  (0), Stratum 3 (secondary reference), poll 6 (64s), precision -25
	Root Delay: 0.010726, Root dispersion: 0.001602, Reference-ID: 0xb9ff5fcf
	  Reference Timestamp:  3998838062.590065126 (2026-09-19T20:21:02Z)
	  Originator Timestamp: 3137907251.455984466 (1999-06-09T08:54:11Z)
	  Receive Timestamp:    3998838106.670166539 (2026-09-19T20:21:46Z)
	  Transmit Timestamp:   3998838106.670250819 (2026-09-19T20:21:46Z)
...

Two things are worth reading here. First, the Stratum field in the reply is the server’s real position in the hierarchy, and it changed from 10 to 3 as the server found its own source, matching what chronyc tracking reported moments later (Stratum 3, reference ID B9FF5FCF). The abstract “chain from 0 to 3” is this one number on the wire. Second, the four timestamps are the whole offset mechanism: the client’s send time (Originator, echoed from the request), the server’s receive time, the server’s send time (Transmit), and the client’s own receive time when the reply lands. From those four the client computes both its offset from the server and the round-trip delay, and corrects its clock by the offset alone. Notice too that the fallback answered at all: even during the seconds before it had a source, the server gave clients a usable reply rather than silence, so nothing downstream loses its time source during the gap.

Network-Wide Time Architecture: It’s Not Just the Servers

In an organization, clock synchronization doesn’t end with the servers; the real gap is in the devices outside them. Firewalls, switches, access points, log servers, camera recorders and IP phones all produce timestamps, and none of them are part of the domain hierarchy. The camera side is especially critical, because a drifting clock directly lowers the evidential value of the footage. So even in an organization that has set up the domain side flawlessly, half the network may still be counting time on its own.

Who Gets Time From Whom?

The right architecture is summed up in one sentence: one point reaches outside, everyone inside is fed from that point. As you read the table below, watch one detail: the rows describe not a device type but a role. The same firewall is the external exit point in one organization and an ordinary consumer in another.

Who takes on the external exit point role varies by organization, with three reasonable candidates: the firewall at the edge of the network, a separate internal NTP server, or the PDC Emulator itself. The firewall is the most practical choice in most organizations, because it’s the device that can already reach outside and you don’t have to open port 123 for any other server. But this is a preference, not a default: if someone else takes the role, the firewall is fed from inside like the other non-domain devices.

Don’t miss the “a DC” phrase in the last row, because in an organization using a domain you may not need to build an internal source from scratch. The Windows Time service runs as an NTP server on a domain controller already, since the domain hierarchy depends on it. Pointing your switches, access points and cameras at a DC’s address is enough, and the cheapest answer, in most organizations. On member servers it’s the opposite: the CIS Benchmark asks for the NTP server to be turned off there, because a member server isn’t an authority that hands time to anyone else.

The log server row carries special weight. Because a log server gathers the records of all devices in one place, if those devices’ clocks disagree the inconsistency becomes visible right there. The moment you trace one incident across three devices’ records is the moment the cost of clock synchronization is paid, as we’ll see in the evidence section below. But that very importance breeds a temptation to give it a privilege, and the trap is there: writing an external NTP address by hand onto a domain-member log server “to be safe” pulls it out of the chain, which breaks the very consistency you were trying to protect.

The Chain Builds Itself Inside a Domain

In an organization using Active Directory the time hierarchy comes ready, and there’s only one machine that needs intervention: the domain controller holding the PDC Emulator FSMO role in the forest root domain. The whole domain takes its time as the reference, so it’s the only server that needs to reach an external source.

# Find which server holds the role
netdom query fsmo

# Run only on the PDC Emulator
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /rediscover

On every other machine, the thing to do is nothing. Member servers and clients take their time from the domain hierarchy in NT5DS mode, and that setting comes with the install.

The most common misconfiguration is right here. A clock problem hits a server, someone writes an external NTP address on that server as a fix, the problem clears, and that line stays. Months later, several independent islands of time form inside the domain; each is correct in its own way and none matches the others. Where a machine gets its time from is told in one line by w32tm /query /source, and running it on every server you suspect takes a few minutes.

Why Isn’t the Default Source Left Alone? The time.windows.com Trap

On a freshly built domain, the PDC Emulator’s configuration usually says time.windows.com, but that address being written there doesn’t mean it’s used. The reason: while the Type field is NT5DS, the NtpServer field is ignored entirely. NT5DS means “take your time from the domain hierarchy,” but the forest root domain’s PDC Emulator is the top of the hierarchy and has no one above it.

The result is an event ID 12 record written to the event log by the Windows Time service, and the machine falling back in practice to its local CMOS clock. The field version is clear: w32tm /query /configuration shows you time.windows.com while w32tm /query /source says something completely different. The setting is there, it isn’t working.

You think the organization’s main clock follows official time; in fact it’s unplugged, running on its own wind-up mechanism. Nobody notices, because it still shows a time. The whole domain’s time has been hung on the battery on that server’s motherboard.

The second question: is it enough to set Type to NTP and actually connect to time.windows.com? Enough for Kerberos, not enough for evidence. Measurements of the Windows Time service show it can’t get below about ±116 milliseconds of absolute accuracy and can’t serve as Stratum 1, while Microsoft’s own accuracy documentation ties every target it supports (1 second, 50 ms, 1 ms) to “an accurate and stable Stratum 1 root source.” The ceiling of the chain sits below the vendor’s own loosest target. Fittingly, Microsoft’s configuration example doesn’t use time.windows.com either, it names a national metrology institute’s server (NIST, in the US). The example is US-based because the document is; what carries over isn’t the address but the principle. Pick your own country’s national time authority.

So where is this set? First, close one misunderstanding: the setting discussed here concerns only the PDC Emulator. There’s nothing to do for other DCs, member servers or clients, they already pull time from that chain. And on a domain-joined machine the Internet Time tab in the Date and Time window is gone: because the clock is managed from the domain hierarchy, Windows removes it, which gives the impression the setting can never be changed. It can, just not from the end-user interface, from the management side, either the w32tm /config command above or Group Policy (not both, one or the other).

There’s one more option, and in environments needing high accuracy or never reaching the internet it’s the right answer: a hardware clock with a GPS or radio receiver placed on the network. Microsoft’s Active Directory best-practice analysis treats this as the first choice and gives an external NTP source as the alternative. The root of the chain then stays inside the organization.

Devices Outside the Domain Don’t Care About Anyone

Devices that aren’t domain members stay outside the time chain, and by default none of them wait to hear from you. A switch keeps running on its factory-set clock, a camera recorder counts the date typed in at first install, an IP phone shows whatever the exchange sends it. None of them errors, because from its own point of view there’s no problem.

What these devices have in common is that the fault is lived not by them but by someone else. The camera records perfectly with the wrong time; the problem lands on the person watching the recording. The switch produces logs with the wrong time; the problem lands on the person reading that log. So until this layer is audited, it never reports itself.

Adding one line to your device-commissioning procedure closes the whole gap: has the device’s NTP been set? Adding it while configuring a switch takes thirty seconds; discovering it two years later takes a day.

When the Clock Drifts: Three Concrete Costs

The faults that appear when clock synchronization is neglected don’t resemble each other, and none of them has “clock” in its name. The three need to be seen separately, because each lands on a different team’s desk.

Kerberos’s Five Minutes: Authentication Stops

Kerberos puts a timestamp inside the tickets it issues to prevent replay attacks, and requires the gap between the client and the domain controller not to exceed a certain tolerance. In Active Directory this tolerance is five minutes by default; when the gap exceeds it, the domain controller rejects the request with a KRB_AP_ERR_SKEW error.

In the lab we measured that this rule doesn’t always work the way it appears to on Windows clients. When the domain controller sends the KRB_AP_ERR_SKEW error, it also puts its own time in the packet; the Windows client reads that, corrects its timestamp and retries, and the session usually opens anyway. The side that genuinely stops is the Linux clients, network devices and systems like NVRs that don’t make this compensation.

The most important detail here is the symptom itself. The device with the drifting clock isn’t cut off the network: it has an address, it pings, it reaches the internet, it sees the shared printer. It just can’t authenticate. And the message on screen doesn’t contain the word “clock”; it usually talks about a trust relationship or the domain being unreachable. That’s why a technician searches for hours on the network side. How the ticket logic works and what the other Kerberos error codes mean is covered in the What Is Kerberos guide.

Timestamp and Synchronization Are Different Things

Two separate concepts are constantly used in place of each other around log records, and it costs an organization dearly in an audit. A trusted timestamp proves to a third party, with an authorized signature, that a record existed at a given date. Clock synchronization makes that date correct in the first place.

The two don’t substitute for each other, because they answer different questions. A record produced by a wrongly-clocked device can be timestamped flawlessly; the timestamp proves the record really was produced at that moment, but it doesn’t correct the fact that the clock the device showed at that moment was wrong. The seal isn’t forged, the sealed information is.

The practical counterpart shows up in an incident review. If the firewall shows a connection at 14:03, the log server shows the same event at 14:09, and the camera recording shows it at 13:58, it looks like three separate events and the chain can’t be built. Correlating one event across several devices is exactly what synced clocks buy you, and it’s why time synchronization is a foundation of monitoring, not a detail; the syslog guide covers the collection side that this reliability underpins.

The Proof an Audit Asks For

In an ISO 27001 audit, clock synchronization is asked about as its own control item (A.8.17), and the auditor’s question isn’t “is NTP installed.” What’s asked is proof: which source are your devices fed from, how do you show it, and when a device loses synchronization, who notices?

What convinces an auditor isn’t the setting itself, it’s the record showing the setting works. A screenshot of w32tm /query /status documents a single moment; an alarm defined for clock drift in your monitoring system documents continuity. Hanging a clock on the wall is easy. What convinces the auditor isn’t the clock, it’s having written down when and against what that clock was set.

The Three Most Common Traps in Clock Synchronization

Even in environments that look correctly set up, three traps come up again and again. All three look fine on the configuration screen, and all three produce the fault much later.

Double Synchronization in Virtualization

On virtual machines, time can come from two separate places: the NTP client running inside, and the hypervisor’s integration service that stamps time onto the guest. When both are on at once, they break each other’s corrections and the clock keeps swinging back and forth.

Picture two administrators setting the same wall clock without knowing about each other. Both do what they believe is right, and the clock is never in the right place.

The heaviest consequence shows up on domain controllers, because a domain controller taking time from the hypervisor conflicts with its own hierarchy and produces replication problems when the clock changes often. The rule is clear: if NTP is used on the guest, the hypervisor’s clock synchronization must be turned off. On the VMware side this means writing tools.syncTime = "0" into the VM’s .vmx file to disable VMware Tools’ periodic sync. On Hyper-V, on the guest, the Enabled value under the HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider key is set to 0 and the w32time service restarted. Both say the same thing: whoever sets the clock, let them set it alone.

The Device That Can’t Resolve DNS, and the Pool-IP Trap

Some devices won’t accept a hostname in their NTP setting, only an IP address, and that drags you toward a solution that looks harmless at first: find the IP behind the address and write it into the device. This is wrong. The pool.ntp.org pool is designed to return different servers on every query; the IP that answers today may leave the pool tomorrow, its owner may change its policy, or it may shut down entirely. The pool’s own usage policy explicitly forbids pinning an IP and embedding the default pool addresses into devices.

Cameras make this concrete: NTP is at its most vital on cameras, because they stamp the time directly onto the image. When footage is requested and the time and date on it are misleading, the recording itself is sound but its date makes it disputable. Older recorders often can’t be given a hostname like a pool address at all, because they have no DNS resolution, the layer that turns a name into an address (covered in the What Is DNS guide); they accept only an IP. And writing the pool’s IP isn’t a durable fix for the reason above. The correct answer is to put an NTP server inside the organization and point every recorder at its fixed internal IP: that server keeps being fed from outside, and the devices get the same time without ever reaching out.

The most practical advice from this section: if you have locations with old DVRs or NVRs, connect to the recorder and review the clock and NTP-server definition under the Settings menu. This check takes ten minutes, and in most organizations it’s a screen no one has looked at for years.

The Internal NTP Server That Stopped Silently

Putting up an internal NTP server has a cost: when that server goes down, no device tells you. NTP clients don’t produce an error when they can’t reach the source, they don’t warn, they just keep counting their own time. The drift restarts from that day, and for months no one notices.

No one notices the wall clock has stopped; twice a day it even shows the right time. The moment it’s noticed is when someone looks at it and is late for an appointment.

The lesson isn’t to avoid an internal server, it’s to put the one you built under monitoring. An unmonitored NTP server is very useful the first year; the second year it turns into a risk the organization doesn’t know it’s carrying.

Diagnosis Order for Clock Problems

When you suspect a clock-caused fault, ask three questions in order: how big is the gap, where does the clock come from, and can the source be reached? The questions are the same on every platform, only the tool you ask with changes. On Windows all three answers come from one tool, w32tm.

# 1. Where the clock comes from, when the last sync happened
w32tm /query /status
w32tm /query /source

# 2. Exactly how many seconds' gap between me and the target (does NOT change the setting, only measures)
w32tm /stripchart /computer:dc01 /samples:5 /dataonly

# 3. Across the domain, which DC is in what state
w32tm /monitor

# 4. Read the configuration, is there a hand-written peer
w32tm /query /configuration

In the output the Source line says where the time comes from, and the Last Successful Sync Time line says when it last actually synchronized. If the second line shows days ago, the device can’t reach its source, and the fault is on the path, not in the configuration.

On Linux the same three questions are answered by:

timedatectl                 # synced or not, which mode
chronyc tracking            # who the source is, how big the gap
chronyc sources -v          # candidate sources and which is selected

On network devices you look at the management interface instead of a command line, and regardless of brand you look for the same two fields: the address of the defined NTP source and the time of the last successful synchronization. The second is not shown on most devices, and where it is, no one looks; yet that’s exactly where the fault hides. On camera recorders this screen is usually the Time tab under Settings.

A short table to get from symptom to source:

The last row is the most insidious, because the configuration screen looks fine. A setting being correct doesn’t mean it’s working.

Conclusion: The Clock No One Looks At

In this article we’ve toured why a clock drifts on its own, how the stratum chain carries time from one source to another, how the device layer beyond the servers is planned, and the costs paid on the authentication, evidence and audit sides when clocks diverge. The one sentence to keep: clock faults don’t say their own name. The symptom is “I can’t join the domain,” “record not found,” “the logs don’t line up.”

Official time is the same. As long as it works, no one wonders about the atomic clock producing it; everyone looks at their own phone and doesn’t even notice they live in a shared time. In an organization’s network too, success isn’t the clock being correct, it’s no one having to talk about the clock.