Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Changing AD NTP time source and potential Kerberos authentication problems

Posted on 2014-03-04
Last Modified: 2015-01-09
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?

Question by:sagdoc
LVL 14

Expert Comment

ID: 39905825
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.
LVL 38

Expert Comment

by:Jim P.
ID: 39906119
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.

Author Comment

ID: 39906348
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?

Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

LVL 26

Expert Comment

ID: 39906753
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.
LVL 26

Expert Comment

by:Leon Fester
ID: 39908926
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.
LVL 26

Expert Comment

by:Leon Fester
ID: 39908947
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.
LVL 22

Accepted Solution

Paka earned 500 total points
ID: 39910340
"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? "

Windows NTP is very robust and most admins "over" administer it.  Your best bet is to sync your PDCE to an external time source and remove any group policy or registry settings on all other machines.  You can use the following batch file to do this on the non-PDCE machines:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time

As previously posted Kerberos is also pretty tolerant and will try to re-authenticate if there is more than 5 minutes of time skew - and will use the authenticating DC time if there is too much drift.  I will double-check in my lab tonight, but I think it might also reset client time too.

"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?"  

This is a pretty interesting (conservative) idea, but I don't think it is necessary.   I'll test in my lab with SQL and Exchange services with a 15 minute drift and report back tomorrow.  Please note that Windows 7 synchronizes time every 7 days by default - so if you go this route, you should wait 8 days for all time to stabilize before reverting the Kerberos policy.

Author Comment

ID: 39913080
Thanks to all of you for your comments.

Featured Post

Best Practices: Disaster Recovery Testing

Besides backup, any IT division should have a disaster recovery plan. You will find a few tips below relating to the development of such a plan and to what issues one should pay special attention in the course of backup planning.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
How to record audio from input sources to your PC – connected devices, connected preamp to record vinyl discs, streaming media, that play through your audio card: Vista, Windows 7, Windows 8, Windows 8.1 and Windows 10 – both 32 bit & 64.
The viewer will learn how to successfully create a multiboot device using the SARDU utility on Windows 7. Start the SARDU utility: Change the image directory to wherever you store your ISOs, this will prevent you from having 2 copies of an ISO wit…
This is used to tweak the memory usage for your computer, it is used for servers more so than workstations but just be careful editing registry settings as it may cause irreversible results. I hold no responsibility for anything you do to the regist…

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question