In a Windows domain it is important that all computers have an accurate clock and that these clocks are (more or less) in sync across the domain. The main reason for this is because the Kerberos security mechanism that provides authentication requires an accurate time source, and without it users and computers will be unable to authenticate one another across the network. That wouldn’t be good.
(The reason Kerberos requires accurate time is because it uses a ‘ticket based’ system whereby security principals get issued security ‘tickets’ that they present to authenticate and access secured resources. These tickets are time-stamped so that they expire quickly and can’t be intercepted and later re-used by an attacker attempting to authenticate. Kerberos v5 has a default maximum clock skew of 300 seconds or 5 minutes. If the computers are more out of sync than that then things stop working.)
“If a client computer sends a time stamp whose value differs from that of the server’s time stamp by more than the value that you configured in the Maximum tolerance for computer clock synchronization setting, the domain controller returns a “KRB_AP_ERR_SKEW” error code in its response packet.”
Normally you won’t have a lot to do with the time service and it will just whirr away in the background ensuring that Kerberos authentication works. When it goes wrong you’ll likely see a variety of errors referencing ‘Clock Skew’ and basically you won’t be able to authenticate against other network members. So suppose you’re unable to connect to one of your domain controllers, DC1, due to clock skew. First confirm that the times are out of sync using the /stripchart switch:
You also want to check where your computer is getting its idea of time from using w32tm /query /source:
Local CMOS clock! That’s no good, we want to get our authoritative time from a DC! (The default authoritative time source for the domain is the PDC emulator). We use w32tm.exe to set /syncfromflags:domhier , which means it will use the domain time source (domhier = Domain Hierarchy):
And finally on your PDC emulator you need a source of time. If no DCs in the domain have a network time source configured then the PDC will fall back to using its internal hardware clock and advertise that as a reliable time source for the domain. This isn’t ideal really, so run the following to sync from online sources:
w32tm /config /manualpeerlist:”pool.ntp.org time.windows.com” /syncfromflags:manual /reliable:yes /update