This article applies to Domain Time II.

Last Updated: 21 Oct 2020

Problem

Time sync with Domain Time Server fails with the logged error "The digital signature of the object did not verify." The full error in the log may appear similar to "ERROR:  Could not verify server response; error 2148098064: The digital signature of the object did not verify"

Cause

Domain Time Servers and Clients have the option of using authenticated network packets to communicate. This option uses a symmetric key method where both the time server and the time requestor have a copy of the shared key which they use to verify authenticity of the packets they exchange. As long as both systems have the same key, communication can proceed. However, if there is a mismatch between the keys used by the components, the authenticated communication will fail resulting in the "digital signature did not verify" error.

Description

As of version 5.1 Domain Time offers two authentication methods: a manually-defined symmetric key process compatible with standard NTP authentication methods, and the proprietary NT5DS-mode automated method used by Windows domains.

In most cases, symmetric key authentication must be intentionally enabled by the administrator, however, Windows Authentication is enabled by default on Domain Time Masters and Slaves.

The Windows Authentication method uses an internal Windows security Identifier (see TechNet: How Security identifiers work) that is supposed to be unique and automatically replicated among all domain member systems to construct the shared authentication key. However, sometimes this RID (Relative Identifier) does not match on some domain members due to changes on the domain (possible causes include merging domains, promoting older DCs, schema upgrades, etc.). If so, then the Windows Authentication of packets will fail.

Since Windows Authentication is enabled by default on Domain Time Masters and Slaves, you may discover this error more often on Domain Time Slaves that cannot synchronize with the Master. Also, on older versions of the software, the inability to communicate with the Master may also cause a machine that is attempting to be configured as a Slave may revert to being an Independent Server as a side effect of not being able to communicate with the Master.

Solution

• If the manual Symmetric Key authentication method is enabled, then you must ensure that all systems are using the same shared key. See the Symmetric Keys page in the Domain Time II Documentation for details on how to configure authentication.

• If the error is caused by a mismatched domain Security Identifier when using Windows Authentication, the solution is to resolve the replication mismatch among the machines on the Windows domain. It may be necessary to demote/remove the mismatched DC and re-add it to the domain to re-establish correct authentication. How best to do this in your environment is beyond the scope of our product. Consult with Microsoft on the best way to accomplish this.

• If you encounter the Slaves that automatically revert to Independent Servers issue due to the communication error, upgrade the Master and Slave to the latest version of Domain Time and re-set the machine to be a Slave.

Workaround

Until you are able to implement the proper resolution detailed above, you can turn off authentication on your affected systems. This is typically done on the "Obtain the time property page of the Domain Time Control Panel applet.

For Masters and Independent Servers, as well as for Clients using defined Time Sources, the setting is found in the settings for each individual Time Source. On the "Obtain the Time" page, you may click "Edit" to change the settings for any listed time sources.

For Slaves and Clients in Automatic Discovery mode, you may uncheck the "Authenticate time samples" checkbox on the "Obtain the Time" property page itself.

Alternately, you may choose to switch your Domain Time Servers to Independent Server mode and ensure they are all set use the same time sources.