Why does time matter? W32Time and authentication dependency

1. Core mechanism

Windows Time service (W32Time) on a domain-member client, time hierarchy of forest, KDC component of authenticating DC, and timestamp on Kerberos preauthentication. This lesson addresses the question 'where does the time source come from and how does the time difference affect authentication'; Kerberos leaves the full structure of the AS/TGS message fields to section 06, while the NTP algorithm details of W32Time to the relevant networking course.

Interfaces and specifications

• W32Time (Windows Time service): Service that aligns the time of member domain according to the hierarchy; Members are in the time client role by default.
• NT5DS (domain hierarchy) time source: Default synchronous mode in which member domain receives time from an authenticating DC.
• PDC emulator (forest root domain): default authorized clock source at the top of the time hierarchy; PDCs of child domains are synchronized from it.
• Stratum indicates hierarchical distance from a reference clock. A lower value generally indicates a closer source; it is not an offset or accuracy measurement. Interpret it with source, synchronization state and measured offset.
• Kerberos Policy / MaxClockSkew ('Maximum tolerance for computer clock synchronization'): the largest clock difference between the client and DC that Kerberos tolerates; default 5 minutes.
• PA-ENC-TIMESTAMP (PreAuthType 2): timestamped preauth data that the client encrypts and sends with the key derived from its password.
• KRB_AP_ERR_SKEW (0x25): Kerberos error returned when the difference between the requested time and the KDC time exceeds the allowed skew; On 4771 it appears in the Status field.

What does the clock check establish?

In this password-based AS example, the client sends PA-ENC-TIMESTAMP: timestamp data encrypted with the client secret key, not merely a clear clock reading.

After key-based verification/decryption, the KDC compares the time with its clock. Being within tolerance satisfies only the freshness condition. It does not validate an incorrect key, an invalid account or other KDC checks.

Replay of an AP authenticator presented to a service is a separate check. RFC 4120 §3.2.3 requires a replay cache or suitable application protection for repeats within the allowed skew. Do not merge that service-side check with the AS preauthentication clock comparison.

Tolerance is finite and configurable: default 5 minutes

The allowed difference is determined by the 'Maximum tolerance for computer clock synchronization' setting in the Kerberos Policy. Location: Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy. The default value is 5 minutes and is configured on the DC.

This lesson assumes that the other KDC checks pass. Within tolerance, the exchange can continue; beyond it, the KDC returns KRB_AP_ERR_SKEW (0x25). Nearby clocks alone do not establish successful authentication.

Unnecessarily increasing this value opens the replay window; Excessive reduction creates brittleness in normal clock shifts. So the solution is not to loosen the tolerance, but to actually keep the clocks aligned.

W32Time retrieves the time from a hierarchy

An AD DS forest has a predetermined time synchronization hierarchy; The most accurate reference clocks are at the top. Domain members are time clients by default and receive their time from an authenticating DC with mode NT5DS. So each machine doesn't have to choose its own random NTP source.

At the top of the hierarchy, the forest root’s PDC emulator of the root domain and is the default authorized clock source. The PDCs of child domains are synchronized from the parent hierarchy, and the member machines are synchronized from their DCs. This chain keeps the domains close to a common, consistent time.

Let's watch a single client throughout this tutorial: WS-034's clock moves forward 12 minutes after a power outage → user attempts to log in before W32Time has yet fixed it → DC sees the skew exceeding 5 minutes → preauth is rejected with 0x25. The changing state is the offset between the client clock and the DC clock.

State and data flow

1. Domain member W32Time receives the clock from a DC (indirectly from the PDC emulator hierarchy) using NT5DS mode.
2. User/machine authentication begins; The client sends preauth timestamped in PA-ENC-TIMESTAMP.
3. DC decodes the timestamp and compares it to its own time.
4. If the offset is within MaxClockSkew, the freshness check passes; authentication continues subject to the other KDC checks.
5. If the offset exceeds the limit, the KDC rejects with 0x25; with Failure auditing enabled, the DC can record 4771 / Status=0x25.
6. W32Time brings the offset within tolerance; a fresh authentication attempt repeats the clock check. Other checks must still pass.

2. Exploitation

Broken trust assumption

The assumption being broken is that time is just 'human read time' and the time difference will distort log timestamps at most. In fact, time is the basis of Kerberos's replay protection; Interference with the clock data and tolerance setting directly affects the authentication result.

Technical prerequisites

• Ability to affect a device's clock or the time source it relies on (e.g. local time change, fake/floating NTP source, non-hierarchical time setting).
• Or incorrect configuration on the defense side: oversized MaxClockSkew or corrupted W32Time hierarchy.
• To go beyond the effect, other prerequisites of the targeted technique (e.g. widening the replay window, cutting DoS with authentication) are also met.

Exploitation mechanism

Clock drift can cause freshness rejection and disruption of fresh Kerberos attempts. Increasing MaxClockSkew accepts a wider time interval without fixing synchronization. It neither removes the replay cache nor grants impersonation on its own. Evaluate clock checks, secret-key verification and service-side replay protection separately.

Clock drift is a DoS vector

Shifting the clock of a group of machines beyond the skew limit collectively breaks the Kerberos preauth of those machines. This is not a privacy violation, but a targeted service outage; On inspection, it appears as cluster 0x25 from many hosts at the same time.

So time infrastructure (W32Time hierarchy, PDC emulator, NTP resources) is not just 'IT hygiene', it's the availability dependency of authentication.

Loosening tolerance is the wrong solution

Increasing tolerance to reduce 0x25 errors allows older timestamps to pass freshness checks. A replay cache or separate application replay protection is still required. Changing the threshold without correcting the time hierarchy can merely hide the symptom.

The correct approach is to keep the tolerance reasonable (default 5 min) and actually align the clocks. This ensures stability without expanding the attack surface.

3. Defense & Detection

Telemetry scope

• Kerberos authentication events are generated only on domain controllers and when the Audit Kerberos Authentication Service subcategory is open.
• 4771 (Kerberos pre-authentication failed) Generated when TGT cannot be issued; Failure Code (Status field in event XML) carries the reason for the failure.
• Distinguishing signal for time difference Status = 0x25 (KRB_AP_ERR_SKEW): The difference between the desired time and the time KDC has exceeded the permissible skew. This should be distinguished from other 4771 causes such as incorrect password (0x18) or expired password (0x17).
• Use w32tm /query /status to inspect source, last successful synchronization and service status. The documented /query /status /verbose example also includes Phase Offset; output depends on the OS version. /stripchart /computer:<DC> measures the offset against a particular DC. Correlate these observations with W32Time events and the 4771 time; one output does not prove the root cause of an entire hierarchy failure.

Events and relevant fields

• 4771 / Status = 0x25: KRB_AP_ERR_SKEW; preauth rejection when time difference exceeds tolerance. It must be interpreted separately from other values ​​(0x17 KEY_EXPIRED, 0x18 PREAUTH_FAILED).
• 4771 / TargetUserName, TargetSid: TGT is the requested principal (user or machine account ending in '$).
• 4771 / ServiceName: typically krbtgt/<REALM>; Indicates request TGT in stage AS.
• 4771 / PreAuthType: preauth type; In password-based flow, PA-ENC-TIMESTAMP (2) is expected.
• 4771 / IpAddress, IpPort: client network context from which the request came; It is used to cluster which hosts the same skew comes from.
• 4771 is Version 0 and produced only in DC; Status codes are based on error set RFC 4120 §7.5.9.

isolate 0x25 from other 4771 causes

4771 is not a single error, it is a failure family. The Status field tells the real reason: 0x25 time difference, 0x18 incorrect password, 0x17 expired password. Seeing the same event ID and counting them all as 'brute force' leads to the wrong root cause.

The signature of the time problem is concurrent 0x25 clusters across different users and hosts; Password guessing generally produces 0x18 on a single target. The clustering pattern and time window determine the separation.

Combine evidence of time with evidence of authentication

4771 Status=0x25 It says 'authentication was rejected due to skew' but does not say why the clock is skewed. It is necessary to combine this with time side evidence such as W32Time/Time-Service events and 'w32tm /query /status'.

Use w32tm /query /status to inspect source, last successful synchronization and service status. The documented /query /status /verbose example also includes Phase Offset; output depends on the OS version. /stripchart /computer:<DC> measures the offset against a particular DC. Correlate these observations with W32Time events and the 4771 time; one output does not prove the root cause of an entire hierarchy failure.

Detection logic · XPath

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4771)] and EventData[Data[@Name='Status']='0x25']]</Select>
  </Query>
</QueryList>

Query assumptions

• This selector selects event nodes from one DC’s local Security log; it performs no multi-host correlation.
• Status is the string 0x25 in this example. Verify the actual mapping if a collector normalizes it.
• The relevant Failure auditing must be enabled on the DC for 4771. The query has not been executed against Windows Event Log.

False positives

• Temporary skew errors before fixing W32Time for devices that have been offline for a long time or have experienced a power outage.
• One-time skew caused by return from virtual machine snapshot or hardware clock battery failure.
• 0x25 events generated by newly installed/lab devices before the first synchronization into the hierarchy.

Hardening

• Set up the W32Time hierarchy correctly: members synchronize with NT5DS from their DC, PDC emulator (forest root) from a reliable external time source; Prevent each machine from selecting ad-hoc external NTP.
• Keep the 'Maximum tolerance for computer clock synchronization' value reasonable (default 5 min); Increasing tolerance to hide skew errors — this opens the replay window.
• Monitor time source health and stratum of PDC emulator; Inventory time infrastructure as a critical dependency and include it in monitoring coverage.
• Validate changes (external NTP source, tolerance, hierarchy) in a pilot environment, gradually implement and prepare a rollback plan; Check for host-time synchronous conflicts on virtual DCs.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4771</EventID>
    <Version>0</Version>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data Name="TargetUserName">birkan</Data>
    <Data Name="TargetSid">S-1-5-21-1533101619-2072831041-1560920683-1442</Data>
    <Data Name="ServiceName">krbtgt/OUTREASON.EXAMPLE</Data>
    <Data Name="TicketOptions">0x40810010</Data>
    <Data Name="Status">0x25</Data>
    <Data Name="PreAuthType">2</Data>
    <Data Name="IpAddress">::ffff:192.0.2.34</Data>
    <Data Name="IpPort">51544</Data>
    <Data Name="CertIssuerName" />
    <Data Name="CertSerialNumber" />
    <Data Name="CertThumbprint" />
  </EventData>
</Event>

Two reality checks

Assumption: The time difference distorts log timestamps the most; It does not affect authentication.

In fact: The Kerberos preauth timestamp must be within 'Maximum tolerance for computer clock synchronization' (default 5 min) with the DC clock. If exceeded, preauth is rejected and KRB_AP_ERR_SKEW (0x25) is returned; so time is a hard authentication dependency.

Assumption: It is best to connect every machine directly to a reliable Internet NTP source.

In fact: In a domain, the correct model is a hierarchy: members are synchronized with NT5DS from their DC, and forest is the default authoritative source in the root PDC emulator. Choosing ad-hoc external NTP for each member breaks the hierarchy; The external source is named structure only at the top (PDC emulator).

Sources

• Microsoft · Maximum tolerance for computer clock synchronization
  Kerberos V5 tolerates max time difference between client and DC clocks; replay attacks; default 5 minutes; Kerberos Policy location
• Microsoft · How the Windows Time Service Works
  AD DS forest predetermined time synchronization hierarchy; stratum; members act as time client by default; clock discipline
• Microsoft · 4771(F) Kerberos pre-authentication failed
  Event XML (Version 0); Status/Failure Code field; RFC 4120 §7.5.9 codes; generated only on DCs; Audit Kerberos Authentication Service
• IETF · RFC 4120 (Kerberos V5)
  §7.5.9 error codes (KRB_AP_ERR_SKEW = 37 / 0x25); timestamp/preauthentication use against replay