Problem
Windows domain clients using the domain hierarchy (NT5DS) may fail to synchronize their time with a UCS Samba AD domain controller.
Typical symptoms are:
w32tm /resync /rediscoverreturns:
The computer did not resync because no time data was available.
- The Windows Time Service reports that the response from the domain controller cannot be authenticated because the expected signature is missing.
w32tm /query /sourcemay showFree-running System Clock.
The issue has been reproduced with:
UCS: 5.2-6
ntpsec: 1.2.3-1
samba: 2:4.24.2-1A~5.2.0.202608111830
Domain Functional Level: Windows Server 2016
msDS-Behavior-Version: 7
Functional Level 2016 corresponds to msDS-Behavior-Version: 7 on the Samba AD DCs.
Investigation
Check the domain and DC functional levels:
samba-tool domain level show
univention-s4search --cross-ncs "(objectClass=nTDSDSA)" msDS-Behavior-Version
For the reproduced case, this returns Windows Server 2016 and:
msDS-Behavior-Version: 7
Capture the NTP traffic while triggering a resync from the Windows client:
tcpdump -ni any -s0 'udp port 123 and host <WINDOWS-IP>'
On Windows:
w32tm /resync /rediscover
The affected configuration shows:
Windows -> UCS: NTPv3 Client, length 120
UCS -> Windows: NTPv3 Server, length 48
Additionally:
ntpq -c mssntpinfo
does not increment the MSSNTP counters for the 120-byte request.
Microsoft specifies that Windows uses a 120-byte MS-SNTP ExtendedAuthenticator request when ExtendedAuthenticatorSupported is enabled. For a selected DC with a DC Functional Level of Windows Server 2012 or newer, Windows enables this behavior. (Microsoft Learn)
The issue has been reproduced with Functional Level 2016. Other functional levels using the ExtendedAuthenticator may potentially be affected as well, but have not been verified in this investigation.
Root Cause
The Windows client sends an MS-SNTP ExtendedAuthenticator request, but the currently used NTPsec/Samba ntp_signd path does not process this request as authenticated MS-SNTP.
As a result, the 120-byte request receives a normal 48-byte NTP response instead of the authenticated response expected by Windows. Windows therefore rejects the response.
The same ExtendedAuthenticator interoperability limitation has also been discussed upstream by the chrony and Samba communities. (Samba Mailing Lists)
A comparison test with the legacy MS-SNTP authenticator shows the difference:
ExtendedAuthenticator:
Windows -> UCS: 120 bytes
UCS -> Windows: 48 bytes
MSSNTP counters unchanged
Time synchronization fails
Classic MS-SNTP:
Windows -> UCS: 68 bytes
UCS -> Windows: 68 bytes
MSSNTP "processed" and "good" counters increase
Time synchronization succeeds
Solution
As a workaround, configure the Windows client to use the classic MS-SNTP authenticator instead of the ExtendedAuthenticator.
Run the following as Administrator on the Windows client:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient" /v SignatureAuthAllowed /t REG_DWORD /d 0 /f
net stop w32time
net start w32time
w32tm /resync /rediscover
Verify the selected time source:
w32tm /query /source
The Samba domain controller should now be reported as the time source.
After applying the workaround, the client sends a 68-byte classic MS-SNTP request and Samba processes it through ntp_signd. This behavior has been reproduced successfully on a UCS test environment with Functional Level 2016 and has also been reported upstream. (Samba Mailing Lists)
For larger environments, the registry value can be distributed through Group Policy.
SignatureAuthAllowed=0 forces Windows to use the legacy MS-SNTP authenticator instead of the newer ExtendedAuthenticator. The setting should therefore be considered a workaround and evaluated according to the environment’s security requirements.
To revert the workaround, restore the value to 1 and restart the Windows Time Service:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient" /v SignatureAuthAllowed /t REG_DWORD /d 1 /f
net stop w32time
net start w32time
What’s next?
We documented this behaviour in a bugreport and will hopefully find a solution for domain levels >=2012. You can track the progress by adding your e-mail address to the CC list.