Be on time!
Since I ran into a similar case last week, I thought I’d blog about it quickly.
I looked into a foreign forest/domain configuration as a friend of mind asked me about what could cause client machine to behave “strange”. By “strange”, he further elaborated, he meant a couple of “Access Denied” messages when accessing shares and services from client machines and GP failing to apply.
A quick look showed a couple of errors, too. One of the more interesting ones was from Kerberos:
Hmm - that one got me interested. Checking the time on the DCs and the client machine I was sitting on revealed that the time configuration was totally screwed. Clocks were off good 20 minutes. Interestingly, the behavior didn’t spread across all machines of but on certain departments that had installed a third party application some time ago. The app has since gone but some strange problem stayed. The problem was clear here: Kerberos authentication relies on time. Clocks between the client and the server (the DC/KDC) need to be within five minutes so that ticket acqusition can occur correctly (well, that’s the default setting).
Since ticket acquisition failed on some of the clients due to the time skew, clients weren’t able to request a service ticket successfully thus weren’t able to access services on remote servers nor apply Group Policy correctly (that would require access to file shares - yet another service). Where do machines get their time from anyway? By default, domain-joined machines would ask their DCs for the time. The PDCe-FSMO role owner is the “authoritative” time source for all DCs - its time is spread across the domain - and if it’s the PDCe-FSMO role owner of the forest root domain, it’s spread across the forest. Brian has a good posting on this: http://msmvps.com/blogs/ad/archive/2008/10/10/what-w32tm-is-it-anyway.aspx
So it looked like a part of the domain wasn’t following the domain time anymore. Indeed, a checked with
w32tm /query /configuration (you may have to run this as an admin with an elevated cmd) revealed:
whereas a “good” machine responded “NT5DS” (for NT5 Directory Services):
I told them what the culpit was and luckily, they had a smart Scripting Guy on board that did some scripting on the machines so that they would change back to sticking with the domain time.
A Group Policy, CompConf\Policies\AdmTempl\System\Windows Time Service\Time Providers\ - “Configure Windows NTP client“Â would have helped them if the time wasn’t too far of yet (within those five minutes) to change the client time behavior back to NT5DS:
(as explained in http://technet.microsoft.com/de-de/library/cc773263(WS.10).aspx#w2k3tr_times_tools_vwtt)
Keep your machines in time - to keep yourself out of trouble!
P.S.: I had a fun moment with my test machine where I tried to set up a “time problem”. It was a Hyper-V VM with Win7 (you can see the screen shot above). It just wouldn’t stick to the fake time that I entered manually although I had changed the time behavior to not sync it with the domain. After a couple of minutes messing with it, I realized that the Hyper-V keeps track of the VM’s time as that is one of the “Integrated Services”:
