The introduction of Kerberos for
authentication in Windows 2000 provided much more secure authentication
than was available with Windows NT. However, because Kerberos provides
secure authentication by comparing time stamps between client and
server, accurate Time Services is critical. Windows 2000 implemented
time synchronization through w32tim.dll and used the Simple Network Time
Protocol (SNTP), which is described in RFC 1769 and uses UDP (User
Datagram Protocol) port 123. SNTP allows time synchronization of
computers within about two seconds. Windows 2000 also provided the
W32tm.exe troubleshooting utility for performing time configuration
modifications.
Windows 2003 increased the accuracy of time
synchronization by adopting the Network Time Protocol (NTP), which has
the capability to synchronize time within milliseconds. Because all
computers—clients, servers, DCs—must all converge on the same time,
accurate time synchronization is important.
1. Time Services Role in Authentication
Because I have never found any satisfactory documents
explaining how Windows 2003 time services works with authentication,
I'm providing it here with illustrations to help explain the concepts. Figures 1 through 5 show details of how Time Services work during the authentication process. In Figure 1,
the user enters a username and password in response to an
authentication request. At that point, the authenticator is created,
which contains the user's public key, certificate, and a time stamp. The
KDC (Kerberos Distribution Center) checks the credentials and, if
valid, allows the user to log in. The time stamp reflects the time the
request was made and is obtained from the client's system clock. The KDC
validates the user account and password, checks the public key and
certificate, and allows the user to log in.
Now let's look more closely at the role of Time Services in that process. Figure 2
shows the internals of the authenticator. The time stamp is encrypted
for security to prevent attacks known as Expired Ticket Acceptance
Attacks and Replay Attacks, discussed later in this section. If the
client's time from the authenticator, compared to the server's system
time, is within the allowable time skew (default is five minutes), then
the request is honored. If the time skew is greater than the defined
value, the server requests the Windows Time Service to correct the time
stamp to allow the logon request to succeed, as depicted in Figure 3.
This allows computers in trusted domains—especially those in different
forests—to authenticate without changing the client's system time for
each request.
note
When the server corrects the client's time when the
skew is greater than the value allowed (default is five minutes), and
within the defined Kerberos user ticket lifetime (default is ten hours),
it is corrected only in the time stamp of the authenticator. It does not change the client's system time.
If a client receives a clock skew error, the server
allows the client to authenticate up to four times before the request is
denied, forcing the client clock to be synchronized with the server
clock.
At this point, illustrated in Figure 4,
the server returns the authenticator to the client with its public key
and corrected system time if necessary, the user obtains a session
ticket, and the logon request is successful.
