In my previous article, I introduced the NTP Pool Project as the recommended alternative to Microsoft’s
time.windows.com public NTP service, and described how to configure standalone Windows servers to update their clocks from external NTP servers. But on a standalone server, allowing the clock to drift out of sync, even days or weeks out of sync, is really more of an annoyance than a problem. (In most cases. But if a standalone server uses an external service that depends on time synchronization, then, yes, it’s a problem, not an annoyance.) The same is not true for any server or workstation that is a member of an Active Directory (AD) domain.
Everything involving authentication within an AD domain depends on the kerberos tickets issued to computers and users by the domain controllers. All kerberos tickets are time-sensitive, a feature designed to prevent an old kerberos ticket from being used to breach security. On Windows, all kerberos tickets issued are valid for 5 minutes. As long as all clocks on all the computers in an AD domain are within this 5 minute window, everything works just fine. But if one computer’s clock drifts more than 5 minutes from the clocks on the other computers, especially the domain controllers, then authentication failures are not only likely, they’re almost certain.
This is known as a clock skew error and will be recorded in the Event Log with a “clock skew too great” error. When this happens, whatever the computer or user was trying to access will not be allowed. To prevent this, you must ensure that all the computer clocks in the AD domain are in sync.
The server that’s in charge of providing a reliable time source to an AD domain is the domain controller that holds PDC Emulator flexible single master of operation (or FSMO, pronounced “fizmo”). (PDC stands for Primary Domain Controller and is a holdover from Windows NT domains.) When a domain member computer queries the AD DNS servers for the NTP time server, the address of the PDC domain controller is one that’s returned.
The first task is to make sure that the PDC domain controller is updating time from a reliable external source. And the NTP Pool Project is the source that I recommend. To configure the Windows Time service on the PDC domain controller, we once again turn to the W32TM command. This time, setting the NTP servers in the “Internet Time” tab of the Date and Time applet of the Control Panel won’t work since we need to options not available in this applet. This is the command to use on the PDC domain controller (this command is one line and broken into two lines here for clarity):
w32tm /config "/manualpeerlist:0.us.pool.ntp.org 1.us.pool.ntp.org
2.us.pool.ntp.org 3.us.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
Here is what the options mean:
/config - queries or updates the Windows Time Service configuration
/manualpeerlist - specifies the NTP servers to use. This is a space-delimited list of DNS and/or IP addresses and must be enclosed in quotes when more than one server is specified.
/syncfromflags - sets what sources should used. Choices are MANUAL (use the manual peer list), DOMHIER (use an Active Directory domain controller), ALL (use both sources), or NO (don’t sync from an NTP server). This must be set to manual because the PDC domain controller is the time source for the AD domain. It cannot update its time from the domain. When you think about this for a moment, you’ll understand.
/reliable - specifies if the server can be used as a NTP time source for other computers. Again, this must be set to yes since it’s the time source for the domain.
/update - commits the changes.
For the configuration changes to take effect, you have to restart the Windows Time service, either from the Services MMC or using the NET commands as shown below:
net stop w32time
net start w32time
The other domain controllers for the AD domain (the ones that don’t hold the PDC Emulator FSMO) should be set to update time from the from the PDC domain controller. This way, if time on the PDC domain controller drifts, the entire domain will drift with it. For the kerberos tickets, it’s important that time on all the computers in the domain be in sync. It’s the time relative to these computers that determines clock skew, not time from outside the domain. This the command to use on these domain controller:
w32tm /config /syncfromflags:domhier /reliable:no /update
Here the /syncfromflags is set to DOMHIER, so it will use the PDC domain controller as the NTP source, and /reliable is set to NO because they don’t hold the PDC Emulator FSMO and therefore are not the reliable time source for the domain. Once again, you need to restart the Windows Time service as shown above.
All member servers and workstations are automatically set to update time from the PDC domain controller when they are joined to the domain. But if you need to set this, use this command, which works on Windows XP and higher:
w32tm /config /syncfromflags:domhier /update
One thing to note is that the PDC domain controller is the reliable time source for the AD domain. In forests that have more than one AD domain, each domain has it’s own PDC domain controller, and therefore its own reliable time source. Make sure that all of the PDC domain controllers for in the forest use the same external NTP service. If not, it’s possible that time between the domains will drift out of sync, and kerberos tickets used to authenticate between domains will not be honored because of clock skew errors.