Why does Kerberos need synchronised clocks, and what is the usual tolerance?

Authenticators are only accepted if their timestamp is close to the receiver's time (typically within 5 minutes), which lets servers reject replays by remembering only recent authenticators; if clocks drift further apart, legitimate logins fail.

The replay defence works like this: a server accepts an authenticator only if its timestamp lies within the allowed clock skew around its own time, and it keeps every accepted authenticator of that window in a replay cache. An attacker who replays a captured authenticator is either caught by the cache (inside the window) or rejected as too old (outside it). Without a time window, the server would have to remember every authenticator forever.

The 5-minute value is the recommended default in the Kerberos specification and in Windows ("Maximum tolerance for computer clock synchronization"). Consequences in practice:

• Every machine runs time synchronisation (NTP; in Windows, the domain hierarchy).
• The time source must itself be protected: an attacker who can shift a server's clock can make old authenticators look fresh or stop logins entirely.
• A laptop whose clock is off by 10 minutes cannot log in, a common support case.

Go deeper:

• Microsoft Learn: Maximum tolerance for computer clock synchronization — the 5-minute default and why it exists.
• MIT Kerberos documentation: krb5.conf — the clockskew setting and the other client defaults.