Solved

Changing AD NTP time source and potential Kerberos authentication problems

Posted on 2014-03-04
8
651 Views
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?

Thanks
0
Comment
Question by:sagdoc
8 Comments
 
LVL 13

Expert Comment

by:frankhelk
Comment Utility
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.
0
 
LVL 38

Expert Comment

by:Jim P.
Comment Utility
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.
0
 

Author Comment

by:sagdoc
Comment Utility
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
0
 
LVL 25

Expert Comment

by:DrDave242
Comment Utility
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.
0
How does your email signature look on mobiles?

Do your employees use mobile devices to reply to emails? With mobile becoming increasingly important to the business world, it is in your best interest to make sure that your email signature looks great across all types of devices.

 
LVL 26

Expert Comment

by:Leon Fester
Comment Utility
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.
0
 
LVL 26

Expert Comment

by:Leon Fester
Comment Utility
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.
0
 
LVL 22

Accepted Solution

by:
Paka earned 500 total points
Comment Utility
"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.
0
 

Author Comment

by:sagdoc
Comment Utility
Thanks to all of you for your comments.
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

This is an article about Leadership and accepting and adapting to new challenges. It focuses mostly on upgrading to Windows 10.
Possible fixes for Windows 7 and Windows Server 2008 updating problem. Solutions mentioned are from Microsoft themselves. I started a case with them from our Microsoft Silver Partner option to open a case and get direct support from Microsoft. If s…
In this video, we discuss why the need for additional vertical screen space has become more important in recent years, namely, due to the transition in the marketplace of 4x3 computer screens to 16x9 and 16x10 screens (so-called widescreen format). …
With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…

762 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

Need Help in Real-Time?

Connect with top rated Experts

7 Experts available now in Live!

Get 1:1 Help Now