This page configures the symmetric keys used by authenticating network protocols such as NTP and DT2.
Note:
If you see the Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the Active Directory page for more information on using Group Policies.
As of version 5.1, Domain Time supports two methods of network packet authentication: Windows Authentication and Symmetric Key Authentication.
Windows Authentication
Interaction with Windows Time (W32time)
Windows Time clients using NT5DS mode (the default) search the Active Directory hierarchy to find a server.
They send a request for the time using their machine RID as the authentication key, and expect the returned
timestamp to be authenticated by the server. Only a DC in the client machine's domain can provide this type
of authentication.
Domain Time v4.x Servers provided for Windows Time clients by setting the W32time service's client portion
to "NoSync" mode and allowing the W32time service's server portion to serve NTP directly. Although the
timekeeping ability of W32time is poor, this approach allowed the DC running Domain Time to continue
serving Windows Time clients. This workaround is no longer necessary.
As of v5.x, Domain Time provides integrated Windows authentication natively for both NTP and DT2 protocols.
This means that W32time clients in NT5DS-mode can get their time directly from any Domain Time II Server
running on a DC exactly as if getting the time from the Windows Time Service on that DC.
Additionally, Domain Time v5.x clients can obtain authenticated time from DCs running either the Windows
Time service or Domain Time.
W32time in NT5DS-mode has distinct disadvantages:
The W32time NTP Server is inaccurate, so even if the DC's clock itself is well-synchronized, the time being
served may not be. W32time clients receiving the time add to the problem, since they are unpredictable as well.
Other ntp clients (such as xntp) cannot synchronize with it.
Domain Time's NTP Server has none of these disadvantages. It can provide standard NTP (with or without NTP auth)
at the same time it provides NT5DS-mode timestamps, and all at extreme accuracy.
It is therefore highly recommended you install Domain Time II v5.x Server on all DCs. You _can_ install Domain
Time v5.x Clients on a DC, but you will then need to enable W32time in "NoSync" mode to provide NT5DS-mode time
if you have clients that need it.
Windows Authentication refers to the proprietary authentication method Microsoft uses to validate time packets
between domain member machines and domain controllers (DCs). As of v5.1, Domain Time fully supports integrated
Windows Authentication for both serving and obtaining the time within a domain.
Important considerations (read the sidebar for more details):
Windows Authentication only works within a domain. That is, all machines exchanging time using Windows
Authentication must be joined to the same domain (or forest).
Windows Authentication only works between domain members and domain controllers.
While the domain member getting the time may be any kind of machine, the machine providing authenticated time
must be a DC. Only a DC can validate the request. Other machines will not know the necessary shared secrets.
Windows Authentication is automatic, requiring no additional configuration on servers or clients.
Domain Time's Windows Authentication works with NTP, DT2-UDP, and DT2-TCP protocols between Domain
Time Servers and Clients. W32time only authenticates using NTP.
Windows Time (W32time) clients using "NT5DS" mode (the default domain member setting) can get authenticated
NTP time natively from Domain Time Server running on a DC.
NT5DS-mode W32time clients may also get authenticated time from DCs running Domain Time Client, however, W32time
must be set to NoSync mode on the DC so that it provides the authenticate NTP timestamp.
Although Domain Time Client will keep the DC's local clock highly accurate, using the W32time service to provide
the authenticated time will result in reduced accuracy to the clients.
Domain Time Clients can obtain authenticated time from Windows DCs running only the W32time service. However,
this is not recommended, since
the Windows Time NTP service does a poor job of keeping the DC's local clock accurate, and
the W32time NTP server itself adds additional inaccuracy to the network time being served.
Recommended settings:
Using Domain Time on your DCs is highly recommended.
For v5.x Server on a DC:
Verify that the NTP Server Enabled checkbox is checked on the Domain Time II Server Serve the Time property page AND
the Windows Time mode: dropdown on the Server's Advanced property page is set to Disabled.
For v5.x Client on a DC:
the Windows Time mode: dropdown on the Advanced property page is set to NoSync.
Other considerations
Cluster Service
The Windows Cluster has a default startup dependency on W32time. It does not require the time service for any other purpose. Thus,
the simple recommendation for installing Domain Time on clusters is to set the Windows Time mode: dropdown on the
Advanced property page to NoSync, which allows the service to be
running to satisfy the startup dependency, but allows Domain Time to set the cluster's clock.
However, you may replace the cluster's startup dependency if you want. After installing Domain Time Client (or Server) on the cluster, use RegEdit
to navigate to the following key:
Change the DependOnService value (omitting the quotation marks) from "W32time" to "Domain Time Client" (or "Domain Time Server" if that's what's installed).
The cluster service will then wait until Domain Time has started before starting the cluster. You can then set the Windows Time mode: dropdown on the
Advanced property page to Disabled.
Reliable Time Provider
DcDiag and other tools sometimes expect the Windows Time service to be running on DCs, even if it's not actually doing anything. These tools
often depend upon the DC being flagged as a reliable time provider.
Starting with v5.x, Domain Time Server, when installed on a DC,
sets the system flags to indicate the machine is serving time and
is a reliable time source. The DsGetDcName() function will report
Domain Time Server v5.x machines on DCs as both time servers and
reliable time sources. Domain Time Server on a non-DC will not
change the existing system flags.
You may override this behavior by editing the registry. In
HKEY_LOCAL_MACHINE\Software\Greyware\Domain Time Server\Parameters
edit (or create) a REG_SZ (string) value called "Set Reliable Time
Provider" and set its value to either "True" or "False" (the
English words, without the quotation marks). If this value is
present and set to True, Domain Time Server will set the two flags
even if it is not running on a DC. This configuration has no
meaning for Active Directory, since only DCs are examined for the
flags. Other tools, however, may benefit from knowing that a
reliable time source is present. If this value is present and set
to False, then Domain Time Server will not change the flags.
Symmetric Key Authentication
v5.x Domain Time Clients and Servers support Symmetric Key Authentication (hash of shared secrets). Domain Time
supports MD5, SHA1 (as of version 5.2.b.20170922), SHA256 (as of version 5.2.b.20190331), and SHA512 (as of version 5.2.b.20190701).
Older versions support MD5-only.
Domain Time Server and Client support symmetric authentication (using SHA1 and/or MD5) of client-server requests using NTP (version 3
and later; AutoKey is not supported), DT2-UDP, DT2-TCP, and DT2-HTTP protocols.
Domain Time also supports broadcasting (both NTP and DT2-UDP) with a shared key and hash. SHA256 hashes are only valid for use with
PTP v2.1. Clients configured with the same key validate packets from the sending server by comparing the computed hash.
Note: Although v5.2.b.20190701 added support for SHA512, this option is reserved for future use. You should not create SHA512 keys.
If an SHA512 key exists in the keyring of an older version of Domain Time, it will be (mis)interpreted as a very long MD5 key.
SHA1 keys are always exactly forty hex characters long. MD5 keys are ASCII text; different implementations of the NTP daemon have allowed
different maximum key lengths. In general, an MD5 key should be composed only from 7-bit ASCII-printable text, excluding space, tab, and
the # character. MD5 keys should be at least 8 characters long, and should not exceed 20 characters. Some versions of NTP daemons
allow lengths of 32, while others have a maximum of 8 or 16. You will need to choose MD5 keys that are interoperable with all of your
various devices and daemons. SHA256 keys must be exactly 64 hex characters long. SHA512 keys are a 128-byte hex string, corresponding to a 64-byte key.
The Keyring
Symmetric Keys are kept in a list containing the Key number and the Key secret (password). This list is also known as a keyring.
The keyring may contain a combination of trusted and untrusted keys.
A trusted key means the key is available to be selected by the component,
but the trusted key is not active until its key number is selected when configuring a
unicast time source in the time sources list (or by using the Broadcast/multicast key section of this page for broadcasts/multicasts).
Untrusted keys are ignored.
There are various ways to configure the keyring on Domain Time II components:
Master and Independent Servers
- manually using the Control Panel applet (on this page)
- importing the keys from a properly-formatted keyring (ntp.keys) file
- importing a previously-exported Domain Time .reg file.
Shared secrets are automatically replicated between Domain Time Masters and Slaves. No configuration of the Slaves is necessary.
Clients
- manually using the Control Panel applet
- importing the keys from a properly-formatted keyring (ntp.keys) file
- importing a previously-exported Domain Time .reg file.
- using Windows Group Policies (See the Active Directory page.)
PTP v2.1 Security Parameter Pointer (SPP):
In addition to shared SHA256 hashes, PTP v2.1 requires that Masters and Slaves use the same SPP value to be able to validate
v2.1 Authentication TLVs. The SPP stored in the keyring may either be zero (which acts like a wildcard) or must match what
the grandmaster sends. If there is a potential for your Slaves to discover more than one Master (such as with a fallback server), we
recommend you use the wildcard setting (0) to avoid synchronization failure if each server has a different SPP.
Import/Export the Keyring (keys file)
Click the
Import/Export link in the Symmetric Keys section, which brings up a dialog
where you can import or export a keyring (*.keys) text file to share among your devices.
This function is very useful if you are sharing a keyring file with other systems running a daemon such as
dtlinux (dtlinux.keys), chronyd (i.e chrony.keys), or ntpd (i.e. ntp.keys).
Hints:
If you have multiple time sources, each may have its own set of symmetric keys. Be sure to import all the keys from all time sources into
Domain Time.
If you are signing outgoing PTP v2.1 delay requests, all of your grandmasters should be configured to accept the same
KeyId for incoming delay requests.
When possible, be sure all of your time systems are working correctly before enabling authentication.
Authentication requires a correct setup on both ends of the connection, and changes at either end can cause a
previously-working connection to fail. Disabling authentication temporarily should always be one of the first steps
when troubleshooting a connection issue.
As of v5.2.b.20190701, you may use Manager to push out the symmetric keyring to multiple machines at once. See the
Reset Keyring command.
This dropdown selects the trusted key to be used when signing Broadcast or Multicast time packets. Note this refers specifically to the "heartbeat" type of time
packets sent to the network on a fixed schedule, as configured on the Serve the Time page.
As with normal Symmetric Key authentication, Clients receiving the broadcast/multicast must also be using the same authentication key to decode the packet.
Symmetric Keys
Group Policy applied indicator in the lower-left corner of the applet,
there are settings on this page that are being overridden by an Active Directory Group Policy. Settings controlled by policy may be greyed-out or you may be otherwise prevented from making a change here.
See the 
Proceed to the Logs and Status page
Back to the Security page