There are two phases in which the computer clock and ticket timestamps are relevant.
Ticket acquisition (TGT, TGS phase)
If a client computer sends a time stamp whose value differs from that of the KDC’s time stamp by more than the value that you configured in the “Maximum tolerance for computer clock synchronization” (SkewTime) setting, the domain controller returns a "KRB_AP_ERR_SKEW" error code in its response packet. In this packet, the domain controller also includes a time stamp of its own clock.
When the Windows client computer receives this packet, it uses the time stamp of the domain controller together with the value of the Maximum tolerance for computer clock synchronization setting to calculate the valid time. Then, the client computer uses the valid time to retry the request. On this second try, the KDC time-check is successful and the TGT is issued to the client computer.
Note This behavior is documented in Request for Comments (RFC) 4430, "Kerberized Internet Negotiation of Keys (KINK)." To see RFC 4430, visit the following Request for Comments Web site:
ftp://ftp.rfc-editor.org/in-notes/rfc4430.txt
Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
Third-party Kerberos runtimes may behave differently. You will have to contact the vendor for specific information about how their runtime responds to this situation..
Ticket Use (AP phase)
The tickets that are issued are stored in the client ticket cache and are sent to a resource server to be authenticated. If the clock of the resource server drifts relative to the domain controller, there are two scenarios in which the ticket is rejected by the resource server.
When the client sends the TGS in an AP request to the server, the server decodes the time-stamp that was created when the ticket was issued, compares it with the local clock, and finds that either of the following conditions is true:
- The ticket is not valid yet (KRB_AP_ERR_TKT_NYV). This enables 2xSkewTime.
- The ticket is already expired (KRB_AP_ERR_TKT_EXPIRED). This enables SkewTime but also considers TicketLifetime.
At the default settings, the ticket is considered valid on a freshly issued ticket if the following conditions are true:
- Server time is up to 10 minutes behind KDC time.
- Server time is up to 10 hours and five minutes ahead of KDC time.
The validity windows shift as the ticket “ages” in the client ticket cache. If the ticket is one hour old, the server clock may be allowed to stretch one hour more into the future in case a).
Note At this time, there is no protocol option to make the resource server update its clock to match the KDC clock, as in scenario 1.
Important The resource server may be the local “interactive logon” service of the computer that the user is logging on to. In this case, ticket timestamps are not checked, and the user successfully logs on despite the time drift. The special case here is that this ticket is always retrieved immediately after the TGT for an interactive logon session is retrieved or refreshed.
Manage relevant policy settings
The default time skew that is allowed on TGT requests is five minutes. To modify the lifetime value, configure the following Group Policy settings:
Computer Configuration/Windows Settings/Security Settings/Account Policies/Kerberos Policy/Maximum tolerance for computer clock synchronization
The default lifetime of a Kerberos ticket is 10 hours (600 minutes). To modify the lifetime value, configure the following Group Policy settings:
Computer Configuration/Windows Settings/Security Settings/Account Policies/Kerberos Policy/Maximum lifetime for service ticket
For more information about the Kerberos time handling Group Policy settings, see TicketLifetime and SkewTime.