Happy Friday everyone! Brandon Wilson here posting on behalf of a new guest author, Sarath Madakasira. So, without further ado...
Working from home has presented challenges in many areas and it is true for time synchronization on computers used at home to connect to work. More specifically, time synchronization on domain-joined computers used from home is potentially affected due to the challenges of remote connectivity.
AD Domains and Forests were designed in an era of high-latency, low-bandwidth work networks and with security as a top criterion. These criteria extended to time synchronization within the Domains or Forests in the form of using NTP protocol enhanced with AD-based security. Time synchronization is also a requirement for Kerberos to function correctly in AD.
PCs that are not part of an AD domain still required time synchronization for usability. They were configured to use simple NTP over the internet to synchronize time periodically, with certain safeguards in place.
Because of the divergent nature of requirements of these two scenarios, they synchronized time from different sources and at varying intervals using different protocols.
Use of VPNs is an established practice for AD Domains, as is time synchronization in the Domain over VPN links. What is new in recent times is the pervasive use of VPNs by almost everyone to work from home and the quality/reliability of the VPNs available in each case. These factors have affected the time synchronization on the domain client PCs at home. Over a period, domain clients with poor domain connectivity can experience loss of domain functionality or other functionality due to their system time drifting too far from the current time.
This post touches upon some configuration ideas for domain clients used for working from home and connecting to their AD Domains remotely.
There are two factors to consider when synchronizing time on a domain machine in a “working from home” situation – security and maximum allowed time error. Domain time sync adequately covers the first aspect but can fall short on time error due to potential remote connectivity issues.
Assuming the domain is synchronized with UTC in some manner, one can synchronize domain clients with simple NTP servers over the internet as a backup mechanism to keep the time on them reasonably accurate. Although this involves the use of unsecured NTP protocol, some techniques can be used to minimize potential risks. NTP servers on the internet tend to be available and reachable from most internet end points.
Suggested Configuration Changes
Please see the Windows Time Service tools and settings reference for more information on W32time service settings. The following changes can be targeted for remote users via GPO or through GPO + ACLs or GPO + WMI filtering, specifics of which are not discussed here. For ideas on how to use WMI filters for policies, see https://docs.microsoft.com/en-us/archive/blogs/askds/fun-with-wmi-filters-in-group-policy
Enable Backup Simple-NTP Sync
The following configures time.windows.com as a backup time server synchronizing every SpecialPollInterval seconds setting described in the next section.
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v Type /t REG_SZ /d “AllSync” /f
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters /v NtpServer /t REG_SZ /d “time.windows.com,0xB” /f
Decrease polling frequency of Simple NTP
This sets up very infrequent polling of the Simple NTP server and quick time convergence. It should allow maintaining time accuracy within a few minutes of UTC on most machines.
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxPollInterval /t REG_DWORD /d 15
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxAllowedPhaseOffset /t REG_DWORD /d 1
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient /v SpecialPollInterval /t REG_DWORD /d 32768
Protection against Large Time Corrections
This configuration prevents a client from accepting large time corrections from any time server. You need to tailor this for your application and choosing too small of a value may prevent time correction.
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxNegPhaseCorrection /t REG_DWORD /d 54000
Reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v MaxPosPhaseCorrection /t REG_DWORD /d 54000
Secure Time Seeding
Secure time seeding feature was introduced in Windows as a means of correcting very large time errors on consumer PCs. Although this feature was not intended to keep time accurate enough for AD Domains, it can help correct large time errors in certain scenarios and allows SSL/TLS to function. The feature is enabled by default on domain machines also. Please refer to the blog post on more details and determine how you would like to use this feature in your domain.
Applying Configuration Changes
GP update triggers W32time service to reload the configuration. Alternately, restarting the W32time service or invoking w32tm.exe config update command works as well.
Additional Considerations
This may not always be practical, but remote machines of critical importance need good timekeeping holdover if they synchronize time over unreliable networks. The parameters mentioned above may need customization for your specific topology.
Please validate your configuration changes for intended results before widespread deployment.
Thanks for reading, and we hope this helps alleviate some time sync concerns for you!
