About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Direct answer: In hosted Windows estates using Kerberos or time-bound tokens, application servers and domain controllers need clocks within a small allowed skew. Beyond that window, users see intermittent “cannot log on”, SSO failures, or API 401 errors while ping and SQL still work. This is a day-to-day synchronisation dependency, not rebuilding time services after a disaster.
Detection belongs in routine monitoring: compare OS time offset on session hosts, app tiers and identity servers before help desk volume spikes.
Why it matters
Authentication protocols bind tickets and tokens to timestamps to limit replay. If clocks differ beyond the configured tolerance, failures can arise in KDC exchanges or when an application server checks a client authenticator. Check the clocks of the peers in the failing exchange rather than only the domain controller. Symptom patterns are cruelly inconsistent: first login fails, retry works, or only scheduled jobs using service accounts fail because they hit a stricter path.
Virtual machines migrated, snapshots restored, or hypervisor time bugs can jump clock without an obvious config change. Hybrid identity adds cloud VM clocks and on-premises DCs into one logical skew budget.
How it works
RFC 4120 (Kerberos v5) requires acceptable clock agreement for relevant exchanges, including the application server comparing its time with the client authenticator. Excessive differences can produce KRB_AP_ERR_SKEW; ticket validity also has time checks. Microsoft documents a five-minute default for Maximum tolerance for computer clock synchronization in Default Domain Policy and the domain-controller effective default. It is configurable: inspect the effective policy rather than assuming every deployment has that value.
Network Time Protocol, RFC 5905, distributes UTC via strata of sources. In the normal Active Directory hierarchy, domain members follow domain time sources, child-domain controllers follow the parent hierarchy, and the forest-root PDC emulator is at the top unless another reliable source is intentionally configured. Record deliberate exceptions and the forest-root source rather than treating each domain PDC as independently authoritative. Skew detection is therefore: what does each host think UTC is, compared to a trusted reference?
RFC 7519 defines JWT exp and nbf claims and allows small clock-skew leeway. Which claims are required and the permitted leeway depend on the application profile and validator configuration. JWT does not have a universally smaller tolerance than Kerberos.
| Signal / hypothesis | Evidence needed |
|---|---|
| Kerberos log explicitly reports skew | Measure the client, server and relevant KDC offsets and correlate with the failing exchange |
| One host cluster fails | Compare affected and unaffected host offsets, time sources and authentication errors; database or application faults remain possible |
| Failures recur at the top of the hour | Correlate measured offset and token validity with scheduled jobs, DNS and other dependency changes |
| Whole site fails after a power event | Check time-source recovery alongside network, identity, database and application startup evidence |
Timing or grouping is a clue, not a diagnosis. None of these patterns alone rules out DNS, database or application faults.
What to choose and why
Monitor offset, not only “is w32time running”: alert when absolute offset exceeds a fraction of your Kerberos tolerance (editorial threshold: investigate above two minutes if tolerance is five).
Document the forest time hierarchy: record the forest-root PDC emulator's reliable source, parent-domain paths and any intentional exceptions. Include guests that must not override that design with arbitrary external pools.
Change discipline: snapshot revert, manual date change, and cross-region VM move belong on authentication risk radars.
Application tier inclusion: Linux workers and containers participating in Kerberos or validating JWTs must be in the same monitoring set as RDS session hosts.
Risks and limits
Time zone display for users is unrelated to UTC skew. This article does not document DR reconstruction of time services.
No Group Policy or w32time commands were run (untested). Non-Microsoft IdP skew limits vary by product configuration.
Sources
Primary sources checked 14 November 2026. Procedures remain source-researched, not lab validated.
- RFC 4120
- RFC 5905
- Maximum tolerance for computer clock synchronization - Windows 10 | Microsoft Learn
- How the Windows Time Service Works | Microsoft Learn
- RFC 7519
- Kerberos authentication overview in Windows Server | Microsoft Learn
Related future topics
Sequencing identity changes; expiring secrets. Managed support — related only.
Learning notes
- Auth can fail while network and database paths remain healthy.
- Kerberos skew budgets are small compared with human-noticeable clock drift.
- A cluster-wide failure suggests a shared dependency; measured offsets and logs are needed to attribute it to time.
- Skew monitoring is steady-state ops, distinct from post-outage NTP rebuild.
- JWT-heavy APIs need the same UTC discipline as domain-joined servers.
This article was originally published on .