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

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
  1. the Windows Time NTP service does a poor job of keeping the DC's local clock accurate, and
  2. 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:

1. Verify that the NTP Server Enabled checkbox is checked on the Domain Time II Server Serve the Time property page AND

2. the Windows Time mode: dropdown on the Server's Advanced property page is set to Disabled.

For v5.x Client on a DC:

1. 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:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\clussvc

  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 MD5 or SHA (ntpd's AutoKey is not supported). Domain Time also supports broadcasting (both NTP and DT2-UDP) with a shared key and hash. 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, take care when using this option. 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. Prior to version v5.2.b.20250101, Domain Time SHA256 keys must be exactly 64 hex characters long. SHA512 keys are a 128-byte hex string, corresponding to a 64-byte key.

When creating or editing a key, as of v5.2.b.20250101, you have the option of generating a random key of the Minimum, Maximum, or the Normal key length for the type of key selected. The default is Normal, which generates a key of a length accepted by most appliances and other servers. Prior versions always generated the maximum allowed length, meaning you had to manually edit the result if you wanted a shorter 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).

Secrets Import/Export Dialog   [Click for smaller size]

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.

 

Broadcast/Multicast Key  Broadcast/Multicast Key: (None) 1 9909

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.

 

 Proceed to the Logs and Status page
 Back to the Security page