Skip to content

Latest commit

 

History

History
148 lines (101 loc) · 8 KB

windows-time-for-traceability.md

File metadata and controls

148 lines (101 loc) · 8 KB
titledescriptionauthorms.authorms.datems.topic
Windows Time for Traceability
Regulations in many sectors require systems to be traceable to UTC. This means that a system's offset can be attested with respect to UTC.
dahavey
alalve
11/04/2021
article

Windows Time for Traceability

Regulations in many sectors require systems to be traceable to UTC. This means that a system's offset can be attested with respect to UTC. To enable regulatory compliance scenarios, Windows 10 (version 1703 or higher) and Windows Server 2016 (version 1709 or higher) provides new event logs to provide a picture from the perspective of the Operating System to form an understanding of the actions taken on the system clock. These event logs are generated continuously for Windows Time service and can be examined or archived for later analysis.

These new events enable the following questions to be answered:

  • Was the system clock altered
  • Was the clock frequency modified
  • Was the Windows Time service configuration modified

Availability

These improvements are included in Windows 10 version 1703 or higher, and Windows Server 2016 version 1709 or higher.

Configuration

No configuration is required to realize this feature. These event logs are enabled by default and can be found in the event viewer under the Applications and Services Log\Microsoft\Windows\Time-Service\Operational channel.

List of Event Logs

The following section outlines the events logged for use in traceability scenarios.

This event is logged when the Windows Time Service (W32Time) starts and logs information about the current time, current tick count, runtime configuration, time providers, and current clock rate.

Event descriptionService Start
DetailsOccurs at W32time Startup
Data logged
  • Current Time in UTC
  • Current Tick Count
  • W32Time Configuration
  • Time Provider Configuration
  • Clock Rate
Throttling mechanismNone. This event fires every time the service starts.

Example:

W32time service has started at 2018-02-27T04:25:17.156Z (UTC), System Tick Count 3132937. 

Command:

This information can also be queried using the following commands

W32Time and Time Provider configuration

w32tm.exe /query /configuration 

Clock Rate

w32tm.exe /query /status /verbose 

This event is logged when the Windows Time Service (W32Time) is stopping and logs information about the current time and tick count.

Event descriptionService Stop
DetailsOccurs at W32time Shutdown
Data logged
  • Current Time in UTC
  • Current Tick Count
Throttling mechanismNone. This event fires every time the service stops.

Example text:W32time service is stopping at 2018-03-01T05:42:13.944Z (UTC), System Tick Count 6370250.

This event periodically logs its current list of time sources and its chosen time source. It also logs the current tick count. This event doesn't fire each time a time source changes. Other events listed later in this document provide this functionality.

Event descriptionNTP Client Provider Periodic Status
DetailsList of time sources used by NTP Client
Data logged
  • Available time sources
  • The chosen reference time server at the time of logging
  • Current Tick Count
Throttling mechanismLogged once every 8 hours.

Example text: NTP Client provider periodic status:

Ntp Client is receiving time data from the following NTP Servers:

server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123)server2.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123); and the chosen reference time server is Server1.fabrikam.com,0x8 (ntp.m|0x8|[::]:123->[IPAddress]:123) (RefID:0x08d6648e63). System Tick Count 13187937

Command This information can also be queried using the following commands

Identify Peersw32tm.exe /query /peers

Event descriptionTime service configuration and status
DetailsW32time periodically logs its configuration and status. This is the equivalent of calling:

w32tm /query /configuration /verbose
OR
w32tm /query /status /verbose
Throttling mechanismLogged once every 8 hours.

This event logs each instance when System Time is modified using the SetSystemTime API.

Event descriptionSystem Time is set
Throttling mechanismNone.

This event should happen rarely on systems with reasonable time synchronization, and we want to log it each time it occurs. We ignore TimeJumpAuditOffset setting while logging this event since that setting was meant to throttle events in the Windows System event log.

Event descriptionSystem clock frequency adjusted
DetailsSystem clock frequency is constantly modified by W32time when the clock is in close synchronization. We want to capture "reasonably significant" adjustments made to the clock frequency without overrunning the event log.
Throttling mechanismAll clock adjustments below TimeAdjustmentAuditThreshold (min = 128 parts per million, default = 800 parts per million) aren't logged.

2 PPM change in clock frequency with current granularity yields 120 µsec/sec change in clock accuracy.

On a synchronized system, most of the adjustments are below this level. If you want finer tracking, this setting can be adjusted down or you can use PerfCounters, or you can do both.

Event descriptionChange in the Time service settings or list of loaded time providers.
DetailsRe-reading W32time settings can cause certain critical settings to be modified in-memory, which can affect the overall accuracy of the time synchronization.

W32time logs each occurrence when rereading its settings, which gives the potential impact on time synchronization.
Throttling mechanismNone.

This event occurs only when an admin or GP update changes the time providers and then triggers W32time. We want to record each instance of change of settings.
Event descriptionChange in time sources used by NTP Client
DetailsNTP Client records an event with the current state of the time servers/peers when a time server/peer changes state (Pending ->Sync, Sync -> unreachable, or other transitions)
Throttling mechanismMax frequency – only once every 5 minutes to protect the log from transient issues and bad provider implementation.
Event descriptionTime service source or stratum number changes
DetailsW32time Time Source and Stratum Number are important factors in time traceability and any changes to them must be logged. If W32time has no source of time and you haven't configured as a reliable time source, then it will stop advertising as a time server, and by-design respond to requests with some invalid parameters. This event is critical to track the state changes in an NTP topology.
Throttling mechanismNone.
Event descriptionTime resynchronization is requested
DetailsThis operation is triggered:
  • When network changes occur
  • System returns from connected standby/hibernation
  • When we didn't sync for a long time
  • Admin issues the resync command
This operation results in immediate loss of fine-grained time sync accuracy because it causes NTP client to clear its filters.
Throttling mechanismMax frequency - once every 5 minutes.

It's possible that a bad network card (or a poor script) can trigger this operation repeatedly and result in logs getting overwhelmed. Hence the need to throttle this event.

Accurate time sync takes far more than 5 minutes to achieve, and throttling doesn't lose information about the original event that resulted in loss of time accuracy.
close