In Microsoft Windows Active Directory networks, as well as other networks implementing Kerberos authentication,  time synchronization (within a few minutes) is also a requirement for successful authentication.  Time, being a good constantly changing shared value between the server and client machines is used to avoid replay attacks.  For example, say your password is “T0p S3kret”.  If the client software sends “T0p S3kret” across the network without encryption (i.e  plaintext), malicious folks running packet sniffers from a suitable vantage point could pickup the password and use it themselves.  Adding encryption to the mix doesn’t necessarily fix the problem either.  Sure, maybe instead of “T0p S3kret” they’ll see 40d9df8ce5bbf1aadbe7c184b12f6b18, but since 40d9df8ce5bbf1aadbe7c184b12f6b18 is the only thing being sent over the wire to prove you are you, it’s the only thing they need to pretend to be you.  Replay attacks happen when you are allowed to use information again (even if that information is encrypted).   Now, if the server is expecting information based on additional conditions beyond just the password, and those conditions are dictated by the server (e.g. Challenge/Response, Salts, etc) we can avoid the problem of having our passwords or password hashes reused/replayed.   If the server knows my password is “T0p S3kret” and it knows that the time is 12:15PM on Dec 28th 2009 it can make a (more) unique hash of the two peices of information “122820091215″ + “T0p S3kret” = “35f9f080ac318318d124ba98f2c7b32b”.  Of course this expects the client to follow the same rules, take the password and the time and give the server a hash of both of those values combined.  A minute later this hash will not be correct and the client and server will have a new value to agree on.  The window of opportunity for successful replay of this information has therefore been limited to 1 minute in this example.  If you are having trouble following this don’t worry, it’s not at all important or relevant to what we’re doing next, this was merely to add some context as to why the correct time might be important to working authentication.

Your PDC Emulator should know what time it is.  This can be done by manually setting the time, interfacing to GPS or other hardware equipment for time, or asking another server for the correct time.  The Network Time Protocol was designed to allow computers to set the correct time from other computers over a network.  It’s a widely used Internet standard, and it’s evolution (along with Simple Network Time Protocol)  is documented over several RFC memorandums (perhaps the most relevant of which are currently RFC 1305 and RFC 2030).  Luckily, Microsoft Windows uses this standard as the basis for their Windows Time service rather than reinventing the wheel.  Because NTP is such a common standard, plenty of resources exist to take advantage of.  The people behind ntp.org run the NTP Pool Project where a large community of volunteer time server administrators can add their servers to a list of publicly accessible time servers.  As a result, we can access this large list of servers by a single address: pool.ntp.org.  We will setup our Windows network PDC Emulator to sync it’s time from pool.ntp.org.  First lets make sure we can communicate to the pool.ntp.org servers.  In a Command Prompt  (CMD.EXE) window issue the following command

You should see something like:

Of course yours should have real addresses and numbers in the result.  The important thing is that you don’t end up with

Which might indicate that the name couldn’t be resolved, or an error like:

Which might indicate that the NTP service on the server was not reachable.  If your having trouble, check out your firewall rules (UDP port 123), perhaps try running the commands again on a different PC within the same network to help isolate the trouble.

Assuming you got what looks like a good response back (nothing that said error, and a line that shows the NTP offset from the local clock),   we can probably continue on to the next step:

If everything goes well you should see “The command completed successfully”.

Run:

To put the changes in effect.   For good measure, you might want to start and stop the Windows Time service:

Workstations on the active directory domain running the Windows Time service should sync to the PDC Emulator automatically.  You can check where a workstation is getting it’s time by running the w32tm /monitor command without the /computers argument:

If your seeing something like this than your probably in good shape.

We can use PsExec to test out the rest of the workstations nearby without getting out of our chair.  PsExec is part of  Mark Russinovich’s sublimely useful SysInternals tools, in the PsTools package.

The first time you run psexec you’ll have to accept the license agreement.  Running commands on all your workstations over the network isn’t the fastest process in the world, so just make sure you have sufficient scroll back buffer in your cmd.exe window, and enjoy some coffee.   When everything is done you might have something like this:

etc, etc…

Don’t worry about the “The network path was not found.” messages, unless you want to try to resolve those, it’s not related to our time synchronization goal, and not in the scope of this text.   Good chance that the machines producing this error were recently turned off, are not functioning on the domain correctly, or have had administrative shares removed.  We’re really looking for systems were w32tm /monitor was able to run, but did not return the expected results.  Workstations running w32tm and exiting with non-zero error codes, or strange messages may need further attention.  Some troubleshooting tips are provided below.

Obviously we can only run remote commands on computers that are turned on and participating on the network, so you might want to run this a couple more times over the course of a few days  to make sure the majority of your workstations are acting as they should.  Or just do what I do and assume everything works until someone tells you otherwise.

Troubleshooting

If the workstation is not getting it’s time from the PDC emulator, try issue the following in a Command Prompt on the workstation:

C:\Documents and Settings\Administrator>w32tm /config /syncfromflagsOMHIER /update
The command completed successfully.

C:\Documents and Settings\Administrator>w32tm /monitor
pdc.mydomain.local *** PDC *** [xxx.xxx.xxx.xxx]:
ICMP: 0ms delay.
NTP: +0.0000000s offset from pdc.mydomain.local
RefID: pool.ntp.org [xxx.xxx.xxx.xxx]

If your seeing something like:

Test to make sure you can find the time server in the domain.  Substitute your Active Directory domain for mydomain below:

If your still having trouble, make sure your RPC service is running, and check your Group Policies in the Group Policy Editor (see http://support.microsoft.com/kb/307882 for help adding the Group Policy Object Editor to the Microsoft Management Console) gpedit.msc under:

Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Windows Time Service -> Time Providers

All 3: “Enable Windows NTP Client”, “Configure Windows NTP Client”, and “Enable Windows NTP Server” should be set to “Not configured” by default.  If these are set correctly and you are still having trouble, try un-registering and re-registering the Windows Time service as described here: http://support.microsoft.com/kb/555584

Wait a moment after stopping the service before un-registering, or you might have to run the command twice:

If this still doesn’t resolve your issue, you might try removing/adding the workstation to the domain again.

Also, if you don’t keep workstations fully patched, make sure you have the proper Daylight Savings Time patches applied