0

Adventures in Windows Time

“The only reason for time is so that everything doesn’t happen at once.”

At work, I have an integrated authentication system based on Windows Active Directory.  All clients, Linux, Unix, and Windows, use Active Directory for user names and passwords.  Active Directory is actually a good implementation of Kerberos.  It does pretty good LDAP as well.  I used some of Scott Lowe’s interoperability blog recipes to get this to work, namely this post for Linux, and this one for Solaris.

One requirement for a reliable Kerberos service is that every clock on every participating machine has to be synchronized.  By default Windows domain controllers act as Network Time Protocol (NTP) servers, and Windows clients know to sync with them.  We configure our Linux and Unix machines to use them as well.

There’s some issues with using Windows domain controllers as NTP servers…

namely, that their time service was designed to just be “good enough” to keep the clocks within the 5 minutes required for Kerberos.  By default, they sync with time.microsoft.com, which isn’t particularly accurate.

I’m not just talking smack about Microsoft, that’s what they themselves say.
“Windows Time service is not an exact implementation of the Network Time Protocol (NTP)…”

So the real issue is getting the first domain controller (not called the primary domain controller any more, but in the case of NTP anyway, it still acts like a PDC) set to get its time from an authoritative source.  By default, on our Windows 2008 domain controller, it seems to use its hardware clock, which wanders around all over the place, time wise.  The rest of the domain controllers by default sync against the first one.

The real solution is to get some Windows friendly hardware attached to the first domain controller, that really does sync with a reliable time source, like the GPS satellites.  Where I used to work I bought a actual stratum one time source like this one from Symmetricom It worked fine.

So the basic idea is to get the first domain controller (PDC) to sync reliably to a network time source, like 0.us.pool.ntp.org.  Then the other domain controllers will be OK.  All clients should be pointed at the domain controllers for their time.  Micrsoft has lots of Technet articles on this like this one for 2008.

Supposedly on the “PDC” (well, first domain controller, anyway) then run this command in a command window as an admin:

net time /setsntp:"0.us.pool.ntp.org  1.us.pool.ntp.org  2.us.pool.ntp.org"

I’m not clear if this “sticks”, that is, stays set after a reboot, or if it actually reliably keeps the domain controller synced to “real” time.  I’ll update this post as I try it in real life.

On linux clients, /etc/ntp.conf should have:

server dc1.yourdomain.com
server dc2.yourdomain.com
server dc3.yourdomain.com

A happy linux client should look something like:

-bash-3.2$ /usr/sbin/ntpq -p
remote     refid    st t when poll reach   delay   offset  jitter
=================================================================
dc1.yourd .LOCL.     1 u   13   64  377    1.131   33.984  10.680
dc2.yourd dc1.yourd  2 u   24   64  377    0.994    4.629   8.372
dc3.yourd dc1.yourd  2 u   19   64  377    1.209   12.256   5.845

dc1 is listed as stratum 1 (st 1) which means that it is the authoritative time source (and is considered atomic clock accurate).  We are lying, as dc1’s’s reference is “LOCL” which means its own hardware clock, which is some silly Dell BIOS clock, not a real time standard.  Oh well.

dc2 and dc3 are listed a stratum 2, who reference dc1.

The “offset” is the amount of milliseconds that your server’s clock varies from the source.  33 milliseconds isn’t so bad.

So to recap:
Make sure the clock on the PDC matches “real” time, like 0.us.pool.ntp.org.  This has to be manually done every so often.  Directions at https://technet.microsoft.com/en-us/library/cc731790%28WS.10%29.aspx.
As an admin in a cmd window, do:
w32tm /config /syncfromflags:manual /manualpeerlist:0.us.pool.ntp.org
w32tm /config /update
(Other dc’s know to follow the PDC.  They automatically sync to algol.)

Make sure esx servers are set to PDC time.
As root (probably need to be on the console, ssh as root is turned off by default in esx):
service ntpd stop
ntpdate dc1
ntpdate dc1 (should be darn close the second time, just milliseconds off)
service ntpd start

Make sure client machines are set to PDC time:
As root:
service ntpd stop
ntpdate algol
ntpdate algol (should be darn close the second time, just milliseconds off)
service ntpd start

Make sure Solaris servers are set to PDC time:
As root:
svcadm disable ntp
ntpdate algol
ntpdate algol (should be darn close the second time, just milliseconds off)
svcadm enable ntp

greg.porter

Leave a Reply

Your email address will not be published.