Problem solve Get help with specific problems with your technologies, process and projects.

Time services: A closer look at Windows authentication

Proper Windows authentication is crucial to maintaining a secure environment. Active Directory expert Gary Olsen explains the important role that time services plays in Kerberos functionality.

Having a good understanding of Kerberos protocol is essential for IT pros dealing with Windows authentication and authorization. Once you master the basics of Windows authentication with Kerberos, it is clear that Kerberos' security functionality is highly dependant on time services.

Let's look further into time services to see how to configure it, how it is used to synchronize computers in the domain and conclude the role it plays in Windows authentication.

First, it's important to know that Kerberos services grants a Ticket Granting Ticket (TGT) to the client upon successfully determining that the presented username/password is what is stored in the KDC database (in the case of Windows, it is stored in Active Directory).

Note that an "authenticator" is created that contains a time stamp (of the ticket), certificate and public key. Kerberos relies heavily on the time stamp for security, so the time stamp is encrypted. When the server gets the ticket, it decrypts the time stamp and compares the client's time to its own. If the difference in time is within a defined time skew, the authentication is successful. In a Windows domain, the time skew is set in Group Policy under Computer Configuration → Windows Settings → Account Policies → Kerberos Policy → Maximum tolerance for computer clock synchronization, and it is five minutes by default.

When the time stamp is read, it is compared to see if the time is the same or earlier than that of the current authenticator (indicating a replay attack), in which case authentication would be denied. If the time difference is greater than the allowed time skew, and if the skew is less than the ticket lifetime, then the time stamp will be adjusted and authentication will be permitted. The server will return its public key to the client, and the client is granted the ticket.

Note: The time stamp in the ticket is adjusted – it does not change the client's system time. Thus, eventually, the authentication will fail if the actual clock on the client is not corrected.

The time skew and time synchronization

Now we know that Kerberos requires that two computers are no more than "time skew" minutes out of sync to authenticate, and in Active Directory environments, this is five minutes. That means clients must be within five minutes of DCs, DCs must be within five minutes of each other and so on. Domain controllers that are out of time skew will fail to replicate and cause authentication to fail as well.

In this case, you will see Access Denied messages in Events and in reports such as Repadmin /showrepl. Well, if that is true, then how could a DC in Seattle ever authenticate with a DC in Atlanta, since they are in time zones that are three hours apart? I answered that question in depth in my January article, Microsoft's daylight-saving time (DST) patch -- Does it matter to AD?, but let's just review a few key points.

Kerberos, as we now know, requires computer clocks to be synchronized within five minutes by default in AD environments. Each computer has a reference clock that is set to Coordinated Universal Time (known as UTC). UTC is synonymous with Greenwich Mean Time (GMT). The Network Time Protocol (NTP) is used to test the synchronization in the domain by examining each computer's reference clock. It is important to note that this reference clock is not affected by time zone calculation.

The time indicator you see in the Notification Area (previously known as the system tray) is modified by an application to show the actual local time, based on the time zone calculation. It does not necessarily indicate GMT – unless you specified your time zone to be GMT. Thus, since the reference clocks all show GMT time, NTP doesn't have to mess with time zones, and the Atlanta and Seattle servers' reference clocks both have a time of, say, 13:05, when the time indicator on the screen shows Atlanta time as 08:05 and the Seattle time as 03:05.

The daylight-saving time feature moves the local time indication ahead or back one hour on certain days of the year, depending on where you live (or not at all if your area of the world doesn't make the DST adjustment). Read more about this in my DST patch article.

The Active Directory domain hierarchy

Figure 1 shows how the AD time services hierarchy is determined. The first DC in the forest is the primary domain controller (PDC) emulator and the authoritative time server for the domain. It breaks down like this:

  • If the PDC role moves to another DC, then that server will be the authoritative time server.
  • When another DC is added, it will use the PDC for its authoritative time source.
  • When client workstations and servers are added to the domain, their authenticating DC will be their authoritative time server.
  • When a child domain is added, the PDC of the child domain will use the PDC of the root domain as its authoritative time server.
  • DCs in the child domain use the child domain's PDC as their authoritative time server, etc.

Figure 1

As far as external time sources go, it is not necessary for Active Directory to sync to an external time source. As long as they are within the time skew, the actual time is meaningless. In other words, if it is 10:00 May 1, 2007, but your computer says it is 8:00 August 27, 1999, and all your computers say the time is 8:00 August 27, 1999, then there is no problem with AD.

Of course, an incorrect date and time will affect applications like Microsoft Outlook. To sync the whole time structure to an external time source, you only need to set the PDC in the root domain to point to an external time source.

Note: You do not (and should not) point the DCs, servers or clients in the rest of the forest to an external time source. In fact, you don't really have to do anything to make this work -- it works out of the box. Just point the PDC in the root domain to the external time source and you're done.

While time sync errors are reasonably rare, they can cause all sorts of problems when they occur. Active Directory replication and user logon, to name just a couple of examples, will definitely generate help desk calls. For more information on how Windows time services works, Microsoft provides an excellent white paper. In the future, we will take a closer look at how to test and troubleshoot Windows time services.

You can follow on Twitter @WindowsTT.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.

Dig Deeper on Windows systems and network management