Microsoft Workloads on AWS
Configure Microsoft Active Directory to use Amazon Time Sync
In this blog post, I will explain how to utilize Group Policy Objects (GPOs) to configure Microsoft Active Directory (AD) to use the Amazon Time Sync Service for time synchronization. Additionally, I will explain how to monitor and alert on the time synchronization health of the domain with Amazon CloudWatch and Amazon Simple Notification Service. Time synchronization is a critical component of the operation of AD and many other distributed computing systems. Without time synchronization, computer clocks will continue to drift and move further away from true time.
Introduction
Announced in November 2022, the Amazon Time Sync Service is available over the internet as a public highly available Network Time Protocol (NTP) service (time.aws.com), which can be used by workloads deployed outside of AWS to synchronize time. For workloads running on AWS, such as Amazon Elastic Compute Cloud (Amazon EC2) instances, we recommend using the Amazon Time Sync Link-Local endpoint (169.254.169.123 IPv4 or fd00:ec2::123 IPv6 address) for the greatest clock accuracy results.
Built on Amazon’s network infrastructure, the Amazon Time Sync Service’s public NTP endpoint at time.aws.com utilizes a global fleet of redundant satellite-connected and atomic reference clocks in AWS Regions to deliver current time readings of the Coordinated Universal Time (UTC) global standard. Customers that wish to avoid deployment and maintenance of enterprise grade NTP server appliances within their environment now have the option to use the Amazon Time Sync service for external time synchronization. This service is provided at no additional charge.
Solution overview
For ease of configuration, a set of GPOs are created and applied to the domain controllers and domain members that contain time synchronization settings. These GPOs are deployed across the AD environment:
- One GPO is created and targeted to the domain controller that holds the PDC Emulator (PDCe) FSMO role to point to the Amazon Time Sync service (time.aws.com). All other domain members will synchronize time from this PDCe using the domain hierarchy. For more information, refer to the article: Configure the Root PDC with an Authoritative Time Source and Avoid Widespread Time Skew.
- A second GPO is created and targeted to all other domain members, including other domain controllers, servers, and workstations in the domain.
- A measure of time synchronization is collected from the PDCe and published to Amazon CloudWatch.
Prerequisites
To implement this solution, you will need:
- AD permissions that allow creating and linking GPOs.
- Outbound network connectivity of UDP port 123 to time.aws.com and TCP port 443 to amazonaws.com from the domain controller holding the PDCe FSMO role.
- AWS account permissions to create custom metrics and alerts in Amazon CloudWatch.
- An Amazon Simple Notification Service (Amazon SNS) topic configured to deliver notifications.
- AWS CLI configured with appropriate credentials on the PDCe to publish the time synchronization metric.
Active Directory time synchronization
With the implementation of the Kerberos V5 for authentication, time synchronization is a critical component of AD. It is best practice for all computer clocks within an AD deployment to have a maximum tolerance of 5 minutes from each other. For more information, see the Microsoft guide: Maximum tolerance for computer clock synchronization.
AD uses a multi-master replication model between domain controllers. If the time is skewed on one of the domain controllers, changes that are made on that domain controller could appear as though it has the most recent change and overwrite the latest changes. Once configured, time synchronization will flow from the PDC emulator to other domain controllers in the topology and from those controllers to other domain members (servers and workstations) as shown in Figure 1.
Figure 1 – AD Time Synchronization
Creating the group policy objects (GPOs)
The easiest way to make use of the Amazon Time Sync service is to configure the settings by group policy. The PDC emulator (PDCe) is configured to synchronize time from the source: time.aws.com. All other domain controllers in the domain will synchronize their time from PDCe. Member servers and workstation will subsequently synchronize time from the domain controllers in their site. There are two GPOs, one targeted for the domain controller holding the PDCe role and one for all other domain controllers and members.
For the highest time accuracy with Microsoft Windows Server operating systems, please see the following Microsoft guide: Configuring systems for high accuracy. Using this guide, the settings to configure are:
PDCe GPO
This GPO should be linked to the “Domain Controllers” organizational unit (OU).
Policy Location: Computer Configuration/Administrative Templates/System/Windows Time Service
Policy |
Setting |
Comment |
|---|---|---|
| Global Configuration Settings | Enabled | |
| – FrequencyCorrectRate | 2 | Controls the rate at which the clock is corrected. |
| – MinPollInterval | 6 | This parameter controls minimum polling interval that defines the minimum amount of time between polls of a peer in log base-2 or 64 seconds. |
| – MaxPollInterval | 6 | This parameter controls the maximum polling interval, which defines the maximum account of time between polls of a peer in log base-2 or 64 seconds. |
| – UpdateInterval | 100 | The number of clock ticks between phase correction adjustments. |
Policy Location: Computer Configuration/Administrative Templates/System/Windows Time Service/Time Providers
Policy |
Setting |
Comment |
|---|---|---|
| Configure Windows NTP Client | Enabled | |
| – NtpServer | time.aws.com,0x9 | External NTP server. |
| – Type | NTP | The type of NTP server. |
| – SpecialPollInterval | 64 | Configures the poll interval in seconds when the SpecialInterval 0x1 flag is enabled. |
Please note the NTP server is specified as time.aws.com with the flags 0x9, which aligns as a client with the polling interval at 64 seconds and the type is set as NTP. For guidance on configuring these parameters with the Windows time service, see the article: Configuring the Time Service: NtpServer and SpecialPollInterval. As it is possible for the PDC emulator role to move to other servers, a target WMI filter is put in place to apply this GPO to the computer that holds the PDC emulator role.
| Namespace | Query |
| rootCIMv2 | Select * From Win32_ComputerSystem where (DomainRole = 5) |
Non-PDCe and member servers GPO
For all other domain controllers and member servers, we want to set the time configuration to pull from the AD hierarchy. This GPO should be linked at both the “Domain Controllers” OU and any other OUs that contain domain server and workstation members.
Policy Location: Computer Configuration/System/Windows Time Service
Policy |
Setting |
Comment |
|---|---|---|
| Global Configuration Settings | Enabled | |
| – FrequencyCorrectRate | 2 | Controls the rate at which the clock is corrected. |
| – MinPollInterval | 6 | This parameter controls minimum polling interval that defines the minimum amount of time between polls of a peer in log base-2 or 64 seconds. |
| – MaxPollInterval | 6 | This parameter controls the maximum polling interval, which defines the maximum account of time between polls of a peer in log base-2 or 64 seconds. |
| – UpdateInterval | 100 | The number of clock ticks between phase correction adjustments. |
Policy Location: Computer Configuration/System/Windows Time Service/Time Providers
Policy |
Setting |
Comment |
|---|---|---|
| Configure Windows NTP Client | Enabled | |
| – Type | NT5DS | The type of NTP server. |
| – SpecialPollInterval | 64 | Configures the poll interval in seconds when the SpecialInterval 0x1 flag is enabled. |
Note that the Type is set as: NT5DS which sets the client to synchronize time from the domain hierarchy and NTP server parameter is effectively ignored. The machines are then targeted using this WMI filter:
| Namespace | Query |
| rootCIMv2 | Select * From Win32_ComputerSystem where (DomainRole <= 5) |
Monitoring the domain time synchronization health
To view the health of time synchronization on a server, the Windows utility w32tm is used to gather time related information from the server:
PS C:\WINDOWS\system32> w32tm /query /status /verbose Leap Indicator: 0(no warning) Stratum: 5 (secondary reference - syncd by (S)NTP) Precision: -23 (119.209ns per tick) Root Delay: 0.0022581s Root Dispersion: 0.0124226s ReferenceId: 0x0356046A (source IP: 3.86.4.106) Last Successful Sync Time: 10/9/2023 9:03:19 AM Source: time.aws.com,0x9 Poll Interval: 6 (64s) Phase Offset: 0.0000001s ClockRate: 0.0156250s State Machine: 2 (Sync) Time Source Flags: 0 (None) Server Role: 576 (Reliable Time Service) Last Sync Error: 0 (The command completed successfully.) Time since Last Good Sync Time: 7.8144300s
From this query, we can then pull metrics related to time synchronization and create a data point called clock error bound, which is a proxy for clock accuracy. For an in-depth description and calculation of clock error bound see the following article: Manage Amazon EC2 instance clock accuracy using Amazon Time Sync Service and Amazon CloudWatch.
| Label | Meaning |
| Leap Indicator | This indicates whether an impending leap second is to be inserted or deleted. |
| Stratum | 5 – This means that our PDC emulator is syncing time with a stratum-4 time source which is time.aws.com. |
| Precision | -23 (119.209ns per tick). This represents the precision of the clock which is expressed as a power of 2. In this case, 2^-23s = 119 nano seconds. |
| Root Delay / Root Dispersion | Root delay represents the round-trip latency of the communication chain from the server up to its stratum 0 reference clock. Root dispersion represents potential errors introduced by clock drift in the time since the server and its upstream sources last communicated with the reference clock. The two together are used in computing clock error bound. |
You can use a PowerShell script to routinely gather and parse the results from w32tm and then publish the clock error bound data points as a custom metric using Amazon CloudWatch. See the article: Publish custom metrics for more information on how to create a custom CloudWatch metric.
Figure 2 – Clock Error Bound in Amazon CloudWatch
With this metric published in Amazon CloudWatch, create an Amazon CloudWatch Alarm and use Amazon SNS to deliver notifications if the clock error bound exceeds a particular threshold. In this example, the clock error bound averages 13.5ms and we will create an alarm if this value exceeds 20ms.
In the Amazon CloudWatch console, choose Alarms and then choose Create alarm. Select our custom metric and set the alarm threshold to 20ms.
Figure 3 – Amazon CloudWatch Alarm
Select Next and in the Configure actions step, and select an existing SNS topic or create new topic to deliver notifications to.
Figure 4 – Amazon CloudWatch Alarm Notifications
Cleanup
To avoid ongoing charges to your account, delete the resources you created.
- Cease publishing the time synchronization metric to Amazon CloudWatch from the PDCe.
- Open the Amazon CloudWatch console, navigate to the list of alarms, and delete any alarms you created.
- In the Amazon CloudWatch console, delete any dashboards you may have created with the custom metric.
Conclusion
In this blog post, I have explained how to setup AD to use the Amazon Time Sync service from an on-premises environment and how to monitor the time synchronization health of the domain. For AWS hosted infrastructure, AWS recommends using the Amazon Time Sync service over the link local endpoint. However, using Amazon Time Sync’s public NTP pools option, you can set up AD on-premises to synchronize to the same highly available time sources previously only accessible from within AWS data centers. This will save you the work and expense of running and managing your own time service.
AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.