KBY Technologies Logo
runbooks/active-directory-kerberos-incident-response/active-directory-kerberos-logons-fail-member-server-clock-skew.md
HIGH SEVERITYActive Directory Kerberos Incident ResponseActive Directory

Active Directory Kerberos Logons Fail Because a Member Server Clock Is Skewed

Severity
HIGH
Target Time
30m
DomainActive Directory Kerberos Incident Response
Verified
Overview

Diagnose Kerberos authentication failures caused by clock skew on a Windows member server and safely restore time synchronization before validating logons.

Share

Destructive Operation

This intervention contains destructive operations. Proceed with extreme caution and ensure database backups exist before execution.

01 // Diagnose

Symptom

Incident signalWhat responders observe

Kerberos-authenticated logons or service connections fail from one Windows member server while the same accounts continue to work from other domain-joined hosts.

Detection Signature

Detection evidenceMetrics, logs, and confirmation commands

  1. On the affected server, run w32tm /query /status and record the source, stratum, last successful synchronization time, and phase offset.

  2. Run w32tm /stripchart /computer:<DC_FQDN> /samples:5 /dataonly and compare the member server with a reachable domain controller.

  3. Run klist and record the Kerberos ticket cache and any ticket errors.

  4. Run nltest /sc_verify:<AD_DOMAIN> to verify the secure channel without changing it.

  5. Review the System event log for Time-Service events and the Security/System logs for Kerberos errors at the incident time.

Root Cause Analysis

Causal chainWhy the incident occurred

  1. The affected member server's clock has drifted beyond the Kerberos tolerance or it is using an incorrect time source.

  2. Kerberos relies on bounded clock skew to resist replay attacks, so otherwise-valid tickets can be rejected while the time difference persists.

02 // Contain & Prevent

Blast Radius

  • Kerberos authentication from the skewed member server can fail for users and services.

  • NTLM fallback may mask the incident for some applications while weakening the expected authentication path.

  • If the incorrect time source affects multiple domain members or a domain controller, the authentication impact can expand beyond one host.

Prevention Measures

Prevent recurrenceControls and architectural guardrails

  • Monitor Windows Time Service synchronization state and offset on domain members and domain controllers.

  • Keep the forest-root PDC emulator synchronized to an approved reliable external source and preserve the domain time hierarchy for other domain members.

  • Alert on repeated Time-Service errors and clock offsets approaching the organization's Kerberos tolerance.

03 // Fix & Intervention

Pre-Flight Checks

Change gateChecks required before intervention

  1. Confirm the affected host is the intended member server and not the forest-root PDC emulator; stop and escalate if the PDC emulator is affected.

  2. Run whoami /groups and confirm the session has the local administrator rights required to manage Windows Time Service.

  3. Record w32tm /query /configuration, w32tm /query /status, w32tm /query /source, and the current system time.

  4. Confirm DNS resolves the intended domain controller and nltest /dsgetdc:<AD_DOMAIN> returns the approved site-local controller.

  5. Confirm the server has network reachability to that controller and that no approved maintenance is changing time configuration.

  6. Windows Time Service has no true dry-run for resynchronization. Immediately before the change, use w32tm /stripchart /computer:<DOMAIN_CONTROLLER> /samples:5 /dataonly as the equivalent impact preview; record all five samples and abort if the source is unexpected, any sample is unavailable, or the largest absolute offset exceeds the application owner's written <MAX_APPROVED_OFFSET>.

  7. Treat starting Windows Time Service if stopped, resynchronizing the clock, and purging only the current operator's ticket cache as explicit mutations. Do not restart an already-running service.

  8. Obtain incident commander and application-owner approval for the measured offset before resynchronizing a latency-sensitive or transaction-processing host.

Execution CommandsCOMMANDS

w32tm /stripchart /computer:<DOMAIN_CONTROLLER> /samples:5 /dataonly; if ($LASTEXITCODE -ne 0) { throw 'Offset preview failed; aborting before mutation' }; if ((Get-Service -Name w32time).Status -ne 'Running') { Start-Service -Name w32time -ErrorAction Stop }; w32tm /resync /rediscover; if ($LASTEXITCODE -ne 0) { throw 'Time resynchronization command failed' }; klist purge; w32tm /query /source; w32tm /query /status

04 // Verify & Recover

Verification Steps

Recovery proofEvidence required before closure

  1. Confirm w32tm /query /status reports a domain-hierarchy source and a recent successful synchronization.

  2. Repeat w32tm /stripchart /computer:<DC_FQDN> /samples:5 /dataonly and confirm the measured offset is within the approved Kerberos tolerance.

  3. Obtain a new ticket with klist get <SERVICE_PRINCIPAL_NAME> for the interactive context.

  4. Separately repeat the originally failing authenticated request under the actual affected service account or application identity; do not treat the operator's ticket cache as proof for another identity.

  5. Monitor Time-Service and Kerberos events for at least 15 minutes.

Rollback Protocol

Safe reversal path

  1. A time resynchronization must not be rolled back to a known-skewed value.

  2. Abort further changes if the post-resync source is not the expected domain-hierarchy source, if the measured offset still exceeds the approved threshold, or if the application reports time-ordering errors.

  3. Isolate the affected application, restore only the recorded approved time-service configuration, stop further manual clock changes, and escalate to the Windows/Active Directory owner before restarting dependent workloads.

Escalation

Conditions requiring additional ownership

  • The affected system is the forest-root PDC emulator or a virtualized domain controller with conflicting host time synchronization.

  • The secure channel is broken after time is corrected.

  • Multiple domain controllers disagree on time or Kerberos failures continue after new tickets are issued.

  • Resynchronization would violate a database, trading, logging, or forensic time-integrity requirement.

Authoritative Sources

Authoritative · Microsoft

Windows Time service tools and settings

Supported w32tm diagnostic and resynchronization commands and Windows domain time-service behavior.

Authoritative · Microsoft

Kerberos authentication troubleshooting guidance

Kerberos failure diagnosis, ticket inspection, clock synchronization, and domain-controller checks.

Authoritative · Microsoft

Restart-Service

The supported PowerShell command for stopping and starting Windows Time Service by service name.

Authoritative · Microsoft

klist

Kerberos ticket-cache inspection, purge behavior, and requesting a ticket for a target service principal.

Authoritative · Microsoft

Start-Process

Waiting for a native process to finish and inspecting its process object for reliable command completion handling.

Active Directory Kerberos Logons Fail Because a Member Server Clock Is Skewed - Incident Runbook | KBY Technologies