r11 - 2018-08-09 - 21:17:25 - HarlanStennYou are here: NTP >  Support Web > OtherImplementations > WindowsTimeService
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
REFACTOR See WindowsTimeServiceDev for discussion of this topic.

13.5. Windows Time Service

Beginning with Windows 2000, Microsoft includes the Windows Time Service with all versions of Windows. Initially, the pupose of Windows Time Service was to keep all clocks on the Windows network loosely synchronized to support Kerberos authentication, which is time-sensitive to a degree. Windows Time Service is also known as "w32time", and can be configured with the registry, Group Policy editor GUI tool, or the command-line tool w32tm.

Windows domain controller machines that are part of an Active Directory domain are automatically configured to act as time servers. The domain controller who is the Primary Domain Controller Emulator in the network is automatically configured to poll time.windows.com as a time source, and all subsequent domain controllors automatically obtain time from the Primary Domain Controller Emulator.

Windows domain member servers and domain member clients are automatically configured to receive time from domain controllers on the same network.

Stand-alone Windows servers and clients are automatically configured to poll time.windows.com at one-hour intervals. The time.windows.com server (actually a cluster of servers) is maintained by Microsoft. However, time.windows.com is notoriously unreliable and heavily loaded, so configuring a different time source or multiple sources is probably wise.

An example configuration, suitable for a Windows 2003 standalone server or Primary Domain Controller Emulator in a Active Directory domain:

C:\>w32tm /config /update /manualpeerlist:"0.pool.ntp.org,0x8 1.pool.ntp.org,0x8 2.pool.ntp.org,0x8 3.pool.ntp.org,0x8" /syncfromflags:MANUAL

The above configuration tells Windows Time Service to use four servers from the NTP Pool, and use a client-mode association (identified by the ,0x8 after each server name) to contact them. This configuration is analgous to server directives in the configuration file for ntpd. Note that this configuration should not be used on Windows servers or clients that are members of an Active Directory domain, unless you absolutely want them to ignore time from Active Directory domain controllers on the network.

A second example, suitable for a laptop computer that is a member of a Windows Active Directory domain:

C:\>w32tm /config /update /manualpeerlist:"pool.ntp.org,0x8" /syncfromflags:MANUAL,DOMHIER

The above configuration tells Windows Time Service to both Active Directory domain controllers and pool.ntp.org as time sources, so that domain controllers are used as time sources when the laptop is on the netowork, but pool.ntp.org is used when the machine is "on the road" but still connected to the Internet (at a WiFi hot-spot in your local coffee house, for example).

For detailed information, please see the Windows Time Service Technical Reference.


The implementations in Windows 2000 and Windows XP are SNTP clients only, and not suitable for use as a server, although Windows 2000 domain conrollers incorrectly serve time at stratum 2 always, regardless of their time source configuration. This is a violation of the SNTP RFC, which states that SNTP systems can only act as servers if they have a local reference clock attached.

More recent versions, such as those in Windows 2003, Vista, and Windows 2008 are documented by Microsoft to be compliant implementations of the NTPv3 RFC 1305.

Windows Time Service servers report a precision of -6, and do not appear to interpolate time between system clock ticks. This limits their absolute accuracy to 16 ms, far below that of the reference ntpd implementaion. However, this accuracy is suitable for many networks and applications.

Reference clock support for the Windows Time Service is possible with third-party drivers. At this time, such drivers are essentially non-existent, meaning Windows Time Service can only act as a time server at Stratum 2 or below.


We should document the 0x8 flag. Talk about the problems with the default w32time setup and noepeer, and how we want to lose the "it's probably a windows client" exemption for noepeer even if we're not actually setting up a peering association.

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r11 < r10 < r9 < r8 < r7 | More topic actions
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback