Avatar of sagdoc

asked on 

Changing AD NTP time source and potential Kerberos authentication problems

I have an AD 2008 domain and am in the process of setting up a reliable outside time source (the domain was originally setup without one, other than using the default PDC).  As of now, all servers and workstations are synced to the PDC.  My intent is to modify the Default Domain Controllers policy to include the following Windows Time service settings:
NTP Server – (outside time source FQDN)
Type – NTP

There are other settings but you get the idea.  This should sync all of my DC’s in the domain with the settings in the NTP Server.  Additionally I was going to create a GPO at the default domain level and set the Type to NT5DS which uses the domain hierarchy (I know this is the default for workstations and servers in the domain but doing this should guarantee it).

I have one big concern before I do this, however.  Currently the domain PDC is about 13 minutes off of the reliable time source.  Once I change the Default Domain to pull the time from the ‘Stratum device’ all of my servers and workstations will be off by 13 minutes.  Is this going to cause Kerberos V5 authentication problems with all
of my applications?  

If I temporarily change the following GPO setting “Maximum tolerance for
computer clock synchronization” from the current 5 minutes to say 15 minutes before I make Time service settings, will this resolve the Kerberos authentication problems until everything eventually syncs up?

Microsoft Server OSWindows OS

Avatar of undefined
Last Comment
Avatar of Frank Helk
Frank Helk
Flag of Germany image

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.
Set that machine to the time of the server.
Set up the server with NTP to follow that machine.
Set all machines up with NTP to follow the server.
On the "time server" machine, stop NTP, set it to a time with a deviation of 7 minutes, which leaves another 6 minutes gap to the server, and restart NTP. The server will smoothly approcht to the "time server" machine, taking it's clients with him.Wait until the server is in sync with the "time source" machine.
Change the server's ntp.conf to sync to the servers from pool.ntp.org (see article). Restart NTP on the server. The server should again wander towards the correct time and get in sync ... taking all the clients to follow like the Pied Piper of Hamelin.
Avatar of Jim P.
Jim P.
Flag of United States of America image

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.
Avatar of sagdoc


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?

Avatar of DrDave242
Flag of United States of America image

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:

That's Microsoft's recommended configuration. It works perfectly for the vast majority of AD environments. (Personally, I've never encountered a problem with the Windows Time service that I couldn't fix, and most of the problems I have encountered were the direct result of people screwing with it.)
It doesn't require a bunch of extra setup. It's perfectly fine to use another scheme and install third-party software to achieve it, just like it's perfectly fine to use standard primary DNS zones in AD and configure zone transfers to replicate them (heck, you can even use third-party DNS server software if you want), but it's going to require more time and effort than simply using AD-integrated zones or simply using Windows Time.

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.
Avatar of Leon Fester
Leon Fester
Flag of South Africa image

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

For more information; see link below about how Active Directory Domain time synchronization works:

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.
Avatar of Leon Fester
Leon Fester
Flag of South Africa image

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.
Avatar of Paka

Blurred text
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Avatar of sagdoc


Thanks to all of you for your comments.
Windows OS
Windows OS

This topic area includes legacy versions of Windows prior to Windows 2000: Windows 3/3.1, Windows 95 and Windows 98, plus any other Windows-related versions including Windows Mobile.

Top Experts
Get a personalized solution from industry experts
Ask the experts
Read over 600 more reviews


IBM logoIntel logoMicrosoft logoUbisoft logoSAP logo
Qualcomm logoCitrix Systems logoWorkday logoErnst & Young logo
High performer badgeUsers love us badge
LinkedIn logoFacebook logoX logoInstagram logoTikTok logoYouTube logo