When Windows workstations are configured to use NT5DS they send NTP client requests to the DC but the DC doesn't respond. When I set the workstations to NTP the DC will respond to their requests. Using Wireshark I've noticed that NTP client packets
from workstations using NT5DS contain a KeyID field and Message Auth Code. Workstations using NTP do not contain those fields. The DC will respond to the latter but not the former.
From what I've read when the DC receives a NTPv3 request with a Key ID it is supposed to check it against the local AD database and confirm it is associated with the client. Since the server is not responding it is my guess that it must be deciding
that the ID is not associated with the client and therefore it ignores the request.
When the server receives an NTP client packet without a Key ID the server responds immediately.
I have read many docs discussing w32tm commands and registry entries, etc. I have come up with a work around by setting the clients to NTP and specifying the DC as the time server but what I'd really like is insight on why the server is having apparent
problems verifying Key IDs.
I can send a packet capture if anybody would like.
Domain controllers and member servers inside the domain
The synchronization type is NT5DS. The time service synchronizes from the domain hierarchy and the time service accepts all time changes. Because NT5DS accepts any time change
without considering the time offset, it is very important to set up a reliable forest root time source in the time sync subnet.
Microsoft is conducting an online survey to understand your opinion of the Technet Web site. If you choose to participate, the online survey will be presented to you when you leave the Technet Web site.