Synchronising time in an Active Directory Forest

Windows Servers use time synchronisation to ensure against replay attacks and thus increase the security of Kerberos authentication within an Active Directory environment. Kerberos tickets are presented to domain controllers by clients and the authenticating domain controller checks that the time stamp on the ticket is within a certain amount of time of the clock on the domain controller, generally 5 minutes although this can be set by group policy. To ensure that the clocks between clients and domain controllers are reasonably in synch at all times, Windows operating systems use the windows time service (W32Time) to synchronise clocks within the forest. They do this by following a synchronisation hierarchy which can be described as below.

  • All client desktop computers nominate the authenticating domain controller as their in-bound time partner.
  • All member servers also nominate the authenticating domain controller as their in-bound time partner.
  • All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner.
  • All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner and synchronise with the server holding the PDC operations master role in the forest root domain.
  • In this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization and should be set to synchronise with an external atomic time source or will use its own CMOS clock to set its internal time.

When deploying domain controllers, the server holding the PDC operations master role must then be granted access to the internet to synchronise its time with an atomic clock using the NTP protocol (UDP port 123). This is fine when a data centre is first deployed but what happens when the PDC emulator operations master role is moved to another server ? Synchronisation will still occur within the forest with the new server holding this role other than for the original server hosting the role which will still synchronise with its external source.

This can raise two issues.

  1. One of the servers, over time, could drift in terms of its clock and so the original PDC emulator may not be in sync with the rest of the forest and therefore reject authentication attempts.
  2. If an application is Active Directory integrated and using the AD servers for its time source then that application or service may not be accurately recording its time in the application or any logs. This can be an issue, for example, for systems “clocking in” staff where staff are fined for late arrival or, perhaps, when accurate recording of access times for network assets is important for security reasons. If the time recorded is out by a few minutes then this may be an issue.

This raises the question then “how do I set my clocks accurately for all machines if I move my PDC Emulator role”. There are three solutions.

  1. Set all domain controllers to synchronise to the same external atomic clock. Whilst this should certainly keep all clocks within a reasonable skew time the same issue can occur as described above if one server should, for some reason, not have external access. It is likely to eventually drift from the other server clocks and create issues.
  2. Set two domain controllers to synchronise externally and only move the PDC emulator role between those two servers. This is a standard answer to this conundrum and can work well. It has the advantage that administrators are likely to know where the FSMO roles are for the domain and reduces the amount of setup time. However, there is still a small risk of drift if one server loses its external access for any reason. There is also the possibility that the PDC Emulator role will be moved to a server other than those nominated.
  3. Use a GPO to set domain controllers to follow the hierarchy above and be compliant with RFC 1305 unless they are the PDC Emulator in which case they go to an external source. While all domain controllers still need to be provided access to the internet over UDP port 123, should a mistake be made then all servers will at least have the same clock time and so, using this method, the likelihood of failed authentication attempts are very much minimised.

The preferred method then is option C above. To configure this is relatively simplistic. A GPO is created and applied at the “Domain Controllers” OU level. The GPO itself is scoped by way of a WMI script to affect just the server holding the PDC Emulator operations master role. This GPO configures the W32Time service on that server with the external clocks to synchronise to.

To create the GPO, open Group Policy Management Console and create a new GOP linked to the Domain Controllers OU (I have called mine PDC Time Sync). Access the Scope tab of the GPO.

Note that WMI Filtering is net to <none>. You can only apply a WMI filter if one exists and so, next, we right click the WMI Filters node above and select “New…“. We give the WMI filter a name and description as below.

We then click Add to add a query to the filter. The WMI query will be as below:

Select * from Win32_ComputerSystem where DomainRole = 5

We then click on OK and “Save“.

The WMI script selects computers whose DomainRole method of the Win32_ComputerSystem class (i.e. DomainRole value) is set to 5. The allowed values for this method are as below.

Value Meaning
0 Standalone Workstation
1 Member Workstation
2 Standalone Server
3 Member Server
4 Backup Domain Controller
5 Primary Domain Controller

 

Active Directory follows the multi-master method of replication whereby each domain controller “owns” a copy of the Active Directory database and can update values in that database and replicate changes to all other domain controllers. This is as opposed to the NT4 methodology where a primary domain controller existed and all other domain controllers were backup domain controllers. However, Active Directory maintains the PDC Emulator role for those times when a PDC is still required for down level clients, password replication and time synchronisation. The server hosting this role has DomainRole 5 and all other domain controllers hold domain role 4, even though they are not backup domain controllers in the traditional meaning of that term.

As the WMI filter now exists it can be assigned to the GPO as a filter. Access the scope tab of the GPO created earlier and set the WMI filter to the one just created.

The GPO can now be edited and values set to control the W32Time service on the server holding the PDC Emulator role. If the role is moved between servers then the GPO ceases to apply and the W32Time settings are reverted to their original values forcing the server to sync to the new server holding the PDC Emulator role. The appropriate policy to set is the “Configure Windows NTP Client” policy found at “Computer Configuration | Policies | Administrative Templates | System | Windows Time Service | Time Providers” in Windows Server 2008 R2. The default values for these settings are shown below.

The meaning of each value is as follows:

Policy Setting Effect of Setting
NtpServer
Establishes a space-delimited list of peers from which a computer obtains time stamps, consisting of one or more DNS names or IP addresses per line. Computers connected to a domain must synchronize with a more reliable time source, such as the official U.S. time clock. This setting is used only when Type is set to NTP or AllSync.

0x01 SpecialInterval

0x02 UseAsFallbackOnly

0x04 SymmetricActive

0x08 NTP request in Client mode

Type
Indicates which peers to accept synchronization from:

NoSync. The time service does not synchronize with other sources.

NTP. The time service synchronizes from the servers specified in the NtpServer registry entry.

NT5DS. The time service synchronizes from the domain hierarchy.

AllSync. The time service uses all the available synchronization mechanisms.

CrossSiteSyncFlags
Determines whether the service chooses synchronization partners outside the domain of the computer.

None               0

PdcOnly          1

All                   2

This value is ignored if the NT5DS value is not set.

ResolvePeerBackoffMinutes
Specifies the initial interval to wait, in minutes, before attempting to locate a peer to synchronize with. If the Windows Time Service cannot successfully synchronize with a time source, it will keep retrying, using the settings specified in ResolvePeerBackOffMinutes and ResolvePeerBackoffMaxTimes.
ResolvePeerBackoffMaxTimes
Specifies the maximum number of times to double the wait interval when repeated attempts fail to locate a peer to synchronize with. A value of zero means that the wait interval is always the initial interval in ResolvePeerBackoffMinutes.
SpecialPollInterval
Specifies the special poll interval in seconds for peers that have been configured manually. When a special poll is enabled, Windows Time Service will use this poll interval instead of a dynamic one that is determined by synchronization algorithms built into Windows Time Service.

 

A list of NTP Time servers can be obtained from http://support.microsoft.com/?id=262680. The values I tend to set for the GPO are as below.

I use the flag 0x1 on the NtpServer setting to make the time service take note of the SpecialPollInterval setting (which is a value in seconds) which sets how often the server should poll for a new time. In this way we can, if desired, poll for a time update more or less often. The NTP type setting tells the service to go direct for its time updates to the NtpServer specified.

One the GPO is configured you can wait for it to be applied to the PDC Emulator or force its application using GPUpdate. To check that the policy is working simply note the difference between the server clock and your wristwatch or other clock and, around an hour later, check again and you should see that the difference between the two time sources has changed as the server is drawing its time from an accurate time source.

The final thing to do is to change the GPO status to disable user configuration settings within the GPO as this will lead to a slightly faster GPO processing time.

 

I hope this post will help remove some of the mystery surrounding how to configure time synchronisation settings within an Active Directory domain.

14 Responses to “Synchronising time in an Active Directory Forest”

  1. Ian Sharpe says:

    Thanks for taking the time to write such an informative article!

    I’ve bookmarked your blog for future reference – keep up the good work 🙂

  2. David says:

    At what point do changes in the GPO go into effect for the time management.

    Does it require a restart of the w32time service?

  3. Philip Flint says:

    The changes go into effect as soon as the GPO is applied – that will be at the end of the group policy refresh interval – this is 5 minutes by default for a domain controller so no more than 5 minutes.

  4. this is really good stuff.

  5. PDF to DOC says:

    Good weblog! I definitely love how it is easy on my eye and the information are well prepared. I am thinking how I might be notified when a new publish has been made. We have subscribed for a rss feed that need to do the key! Have a good day!

  6. Bruce says:

    Hello great write up. I have a question, what is your suggestion please in the event that the PDC goes down say if it was located in a data centre? Obviously I would need to drag the PDC FSMO role off the downed PDC and transfer to another DC at another site, then open UDP port 123 to allow the new PDC to point to an external time source and then update the Time GPO to reflect these changes? This sounds time consuming to me. I need to implement a proper DR plan that would get my domain up and running as quickly as possible as we have had this issue happen twice in our domain and no servers can log on in the data centre. Do you know a quicker more efficient way of accomplishing this? I was thinking about having 3 NTP servers say in a pool so if the PDC goes down it won’t effect the domain, but your GPO seems like a good way to go but I’m unsure how the failover part would get things up and running quickly should the PDC go down. Thank you for your time, hope this makes sense. Bruce.

  7. Gordon says:

    Great information!!! You covered the topics very well. The largest problem I see in general is the misconception that time services will work out-of-the-box with Microsoft Server products. The importance of time synchronization is not respected by most sysadmins and to top it off it is not well documented by Microsoft. I have run into a problem documenting (verifying) the drift tolerance between two domain controllers running Server 2008R2 in a 2003 functional forest. I have found some sketchy information that said a Domain Controller if configured to sync with another DC (not the PDCe) will only tolerate less than a 5000ms drift for 15minute duration and then it will consider itself unreliable for time and no longer provide the NTP service to clients. To top it off it will start passing authentication requests to the PDCe unless the PDCe is unavailable on the network. In a large site that is mis-configured this will result in an eventual failure to replicate the LDAP directory. Do you know the toleration of drift between two DC? And do you know where I can find official Microsoft documentation of the range?

  8. Philip Flint says:

    Hi Gordon,

    What you say is true. By default the LargePhaseOffset is set to 5 seconds – if the clock keeps drifting for a prolonged period (SpikeWatchPeriod) then the server will be marked as an unreliable time source and the behaviour you note will be followed. The above times are set in the registry (LargePhaseOffset – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 50000000=5 seconds, SpikeWatchPeriod – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config 900 = 900 seconds or 15 minutes).

    The official Microsoft documentation for this can be found at http://technet.microsoft.com/en-us/library/cc773263.aspx.

    Hope this helps you out

    Phil

  9. Philip Flint says:

    Hi Bruce

    In simple terms your environment will continue to work, each server and client will have a clock but they will start to drift. If you seize the PDC role then clients will start to sync back (through the other DC’s) to that new PDC. In this way all servers and clients will be using the same time. If you then allow that “new” PDC to contact a new NTP source (by opening the firewall) then that new PDC’s time will be accurate against an atomic clock.

    In effect, in a DR situation there is no real rush for most people to ensure that cleocks are accurate to within a second or so. To reduce the time to revover you can set firewall rules beforehand to allow your main PDC role holder and any secondaries to transit the firewall on UDP port 123. In the event that the PDC emulator role holder fails you can then simply transfer the role to one of your designated seondary servers and everything will resolve itself.

    Phil

  10. bob pellerin says:

    Do I have to go back to my PDC and remove the ntp servers it was pointing to? After putting the GOP in place as shown above, when I go onto my PDC and enter “w32tm /query / source” it still displays the ntp sites that were originally configured. I would think that the GOP would override?

  11. bob pellerin says:

    nevermind. GOP overrode as expected. thanks for this.

  12. Rom says:

    Hi Phillip

    I found the information in this article very helpful, clear and easy to follow and implement. I then used GPO to Synch time in AD and found that the PDC was reporting the event ID 47

    Event Type: Warning
    Event Source: W32Time
    Event Category: None
    Event ID: 47
    Date: Date
    Time: Time
    User: N/A
    Computer: ComputerName
    Description: Time Provider NtpClient: No valid response has been received from manually configured peer NTP_server_IP_Address after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. For more information, see Help and Support Center at http://support.microsoft.com.

    After a few minutes of google search, found the KB http://support.microsoft.com/kb/875424 with a resolution but not using the GPO, which I like and did not want to reverse.

    It says that to resolve this problem, configure Windows Time to use client mode when it synchronizes with the time server; then I updated my GPO and set the NtpServer to ntp.server.com,0x8, then on the PDC server run gpupdate /force, restarted the windows service and problem was resolve,the logs show The time service is now synchronizing the system time with the time source.

    Thought I share it with you.

  13. David McKeon says:

    Hi Philip

    Excellent article. Many Thanks

  14. bob pellerin says:

    when i now query my pdc to display its time source:

    >w32tm / query / computer: /source

    I get only the FIRST entry, up to the space reported back, even though I have typed in three space delimited time servers as follows:

    time.nist.gov,0x1 0.pool.ntp.org,0x1 1.pool.ntp.org,0x1

    Should the w32tm query be showing all of my entries?

    Thanks,

Leave a Reply