Changing AD NTP time source and potential Kerberos authentication problems

Hmmm ... W32time, the timekeeping service in Windows. I experienced enough trouble with that piece of crap when in NTP mode to avoid using it whenever I can.

My recommendation:

Use a Windows port of the classic *ix NTP service, sync a master (or two, three) with an external source (i.e. from pool.ntp.org) and sync the clients and DCs to the master. The NTP service software is free. Easy to install and configure, works like a charm and is stable as a rock. And it is nicer when it comes to one of the rare cases of troubleshooting.

See this article for the "How To".

The NTP service has a low ressource footprint, therefore the NTP functionality could be hooked onto existing machines or VM's like webservers, ftp servers, mailservers or database hosts - even in a DMZ - without visible performance impact.

If securtity is an issue, you might as well place radio controlled clock appliances into your LAN who serve time very reliable and precise.

About your current time difference:

13 Minutes is a bit much ... but there's hope for a smooth transition.

NTP handles initial time differences by tuning the clock to run faster/slower, until the clocks are in sync. This which results in a "smooth" landing and circumvents "hard" steps. If you set up the classic NTP client with the command line options "-x -g" (could be done in the registry - edit HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTP\ImagePath) it will tolerate a deviation of up to 10 minutes and subsequently syncs smooth.

To handle your 13 Minutes, I would temporarily set up a "time server" machine with a NTP client that syncs to it's local clock.

I'm with frankhelk in that you should pick one or two internal servers that all the clients and other servers sync with. Those servers go out to the net to get the time. The rest sync to those.

That is a good idea, but what about the Kerberos maximum tolerance setting.  I understand a major reason for a synced domain is Kerberos tickets require it.  Would bumping up that value before the NTP changes occur resolve the Kerberos issue at least temporarily until everything is in sync?

Thanks

I'm going to go the other way and recommend only synching the PDC Emulator with the external time source, then letting everything else use the domain hierarchy to sync. I have two main reasons for this:


As with any major configuration change that will affect most or all of the machines in your environment, significant changes to your time configuration should be performed during a planned after-hours maintenance window - if something goes wrong, you don't want everyone suddenly getting Kerberos errors in the middle of the workday.

The time service should be able to handle a time change of 13 minutes with no trouble, unless you've set the MaxPosPhaseCorrection and/or MaxNegPhaseCorrection registry values to something small. These values designate the maximum positive or negative time shift that the Windows Time service is allowed to make, and by default they're both well above 13 minutes.

I agree with DrDave242.
Only your PDCe should be syncing with an external time source.

Microsoft has designed the AD time-sync hierarchy with it as the authoritative time source.

AD is a pretty well designed solution so it will already take care of any major time sync changes in your domain.

I'd suggest not doing this during production hours to reduce the risk for downtime for any users/applications.

Here is what happens when a Windows client finds it's clock skew is too great.

Although the "0x25 - KRB_AP_ERR_SKEW: Clock skew too great" error might show up in the logs, it will not prevent a user from being authenticated. When this error is returned, the domain controller also supplies the correct time on the domain controller. The Kerberos client uses the correct domain controller time to attempt the authentication request a second time. Presuming that the user’s credentials are valid, the user will be authenticated on the second try.

The information above was extracted from http://technet.microsoft.com/en-us/library/cc780011(v=ws.10).aspx

So if the time if being pushed down by the DC's it makes sense to use the Microsoft recommendation on DC synchronization.

How to configure an authoritative time server in Windows Server
http://support.microsoft.com/kb/816042

For more information; see link below about how Active Directory Domain time synchronization works:
http://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

Free tip:
The most basic way to get a workstation to re-sync time with the DC is to restart it.
There are also other tools as well....but a domain time re-sync project should not have major issues since AD already has resilience build around such an event.

Do a quick test by simulating your scenario. Must be done on a domain attached workstation.

Test 1:
Change the time of your workstation to 13 minutes less than the current domain time while you're connected to the network and see what happens when you try accessing some of your network applications/resources.

Test 2:
Disconnect workstation from network, change time (-13 minutes from domain time), logoff, re-connect workstation to network and try to login.

Thanks to all of you for your comments.