Back to All Scenarios
PASSEDserver / ntp_clock_drift

NTP Clock Drift — Kerberos Authentication Failures

The NTP server goes offline and server clocks begin drifting. After 3 hours, the domain controller clock is 7 minutes ahead of workstations. Kerberos authentication fails because the maximum clock skew tolerance is 5 minutes. Users cannot log in, access file shares, or use any domain-authenticated service.

Pattern
UNKNOWN
Severity
CRITICAL
Confidence
85%
Remediation
Auto-Heal

Test Results

MetricExpectedActualResult
Pattern RecognitionUNKNOWNUNKNOWN
Severity AssessmentCRITICALCRITICAL
Incident CorrelationYes47 linked
Cascade EscalationYesYes
RemediationAuto-Heal — Corax resolves autonomously

Scenario Conditions

Windows domain with Kerberos auth. NTP server offline for 3 hours. DC clock drift: +7 minutes. Max Kerberos clock skew: 5 minutes (default). 500 workstations. All domain-authenticated services affected.

Injected Error Messages (3)

NTP service down on DC-01 — w32time service stopped, Event ID 134: time client was unable to reach time source, server clock drifting, current offset: +7 minutes from reference, no external time peers reachable, stratum: 16 (unsynchronized)
Authentication failures due to clock skew — KDC error KRB_AP_ERR_SKEW (0x25), clock skew too great between DC-01 and workstations, Event ID 4771: pre-authentication failed, 500+ workstations unable to authenticate, domain logons failing with 'There is a time and/or date difference between the client and server'
File server access denied — SMB authentication failing due to clock skew, users receiving 'Access Denied' on mapped drives, fallback auth blocked by policy, Event ID 4625: logon failure (clock skew), all domain-authenticated file shares inaccessible

Neural Engine Root Cause Analysis

The Windows Time service (w32time) on domain controller DC-01 has stopped, causing complete NTP synchronization failure. Event ID 134 indicates the service cannot reach external time sources, resulting in clock drift (+7 minutes) and stratum 16 (unsynchronized state). With 17 correlated incidents in the same timeframe, this suggests either a cascading failure from the DC being down or a broader infrastructure issue affecting multiple services that depend on this domain controller for time synchronization.

Remediation Plan

1. Restart the Windows Time service (w32time) on DC-01 via remote service management. 2. Verify network connectivity to external NTP sources (pool.ntp.org, time.windows.com). 3. Force immediate time synchronization using 'w32tm /resync /force'. 4. Check Windows firewall rules for UDP port 123. 5. Validate NTP configuration in registry and Group Policy. 6. Monitor stratum level and time offset to confirm synchronization recovery. 7. Address any underlying network or DNS issues preventing external NTP access.
Tested: 2026-03-30Monitors: 3 | Incidents: 3Test ID: cmncjooeu03avobqexoz18hn4