Active Directory Monitoring: The AD Time Service - Part 1

It is always recommended to utilize Active Directory monitoring to help you maintain a healthy authentication and authorization infrastructure. The Windows Time service is a critical component in being able to authenticate users that are using the Kerberos V5 services used by Active Directory. However, some questions usually come up as to how the Windows Time service works and what information should you be looking for when your AD monitoring system finds issues.

This two-part article will take you through the history of the Windows Time service and how to manually monitor your AD environment using the tools included in the Windows Operating Systems.

[Applies to Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 10 or later]

AD Time Synchronization Origins: Network Time Protocol (NTP)

Network Time Protocol (NTP) is a networking protocol that is used for clock synchronization in computer systems over packet-switched data networks. NTP was designed by computer engineer and internet pioneer David L. Mills, PhD from the University of Michigan and has been operation since 1985. The intention of NTP is to be able to synchronize all computers that are a part of the network to be synchronized within a few milliseconds of Coordinated Universal Time (UTC).

NTP is used in both client-server models, as well as peer-to-peer relationships when both computers (peers) consider the other to be a time source. In these types of implementation, the peers send and receive sequences of encoded information or characters that identify when an event occurred, also known as timestamps. The information within timestamps will give the date and time of day that can be accurate to within fractions of a second. This information is sent over User Datagram Protocol (UDP) over port 123. Packets are sent and received using broadcasting or multicasting, allowing client machines to passively listen to time updates after the initial round-trip communication.

The important thing to remember is that no client will ever be more accurate than its source (server or peer). The accuracy of your client time will also depend on the time source being used. You need to ensure good-quality health of your data network as slow and non-predictable networks with varying delays will cause errors of 100ms or greater. NTP can also operate by using direct queries.

NTP, W32time, and Windows OS

So how does the Windows Time Service keep your local computer time accurate? The simple answer is that w32time synchronizes the local computer clock to the defined time source clock. It is able to achieve this by using time sampling from the remote system. Here is a basic diagram of the four-step synchronization process between a client and its source server:

Microsoft operating systems use the Windows Time Service (W32Time) which is based off of NTP. W32Time uses complex algorithms based off of NTP specifications to help ensure that all clocks are accurate as possible. So why does the Windows Time Service exist? With the release of Windows 2000, many new authentication features were released. The main authentication feature being Kerberos authentication. The Kerberos protocol requires any client computer using the Kerberos authentication to have their clock “synchronized” to within 5 minutes of the authentication server clock time.

Why does time synchronization matter?

Time Source Selection

NTP is much more straight forward as it will just try to sync with its specified peer. We will often see this this mode utilized with non-domain joined computers. The default value we find with the Windows Operating Systems is time.windows.com which is an NTP server hosted directly by Microsoft. If you have ever noticed that PCs with Windows show the proper time as soon as they are turned on (minus the time zone attribute), now you understand why.

What about NT5DS mode? NT5DS is utilized by domain-joined computers using domain lookup mechanisms. More specifically, it uses netlogon API calls that will find a suitable peer to synchronize. When looking for a peer to synchronize, for optimization purposes, domain joined windows machines will look for a domain controller from their own site or domain. If none can be found, the next alternative is to look for a domain controller that is utilizing the Primary Domain Controller (PDC) Flexible Single Master Operation (FSMO) role, which can sometimes be located outside of their site or domain.

Active Directory Time Synchronization Architecture

The first rule of thumb when deploying your Active Directory environment is to only configure one computer with a time server, and that computer should be the computer holding the PDC Emulator FSMO rule within the forest root domain. This will serve as the time source for all other domain controllers, member servers, and domain-joined workstations running Windows in your Active directory forest. By default, the configuration for all other domain members is to have time synchronize with the forest PDC emulator, whether it be directly or indirectly. Here are some rules to know about how time synchronizes in an AD DS hierarchy:

2) Domain controllers in child domains will synchronize their time with any domain controller in the parent domain or a domain controller holding the PDC emulator role in their own domain.

3) Any time you have a PDC Emulator FSMO role-holder in a child domain, they will synchronize their time with domain controllers in their parent domain. That would include a domain controller in the parent domain with the PDC Emulator role.

Another term we need to look at is called stratum. Stratum is the degree to which a computer’s time is accurate. For example, the lowest stratum level would be the equivalent to the most accurate time source on your network. For every synchronization step we take further away from the reference clock will be a stratum one level higher. The PDC emulator in the forest root domain would be the most accurate clock and therefore would be the lowest level stratum. For every domain controller that would then synchronize it’s time from the PDC emulator would be the next higher-level stratum. Resources that get their time from the domain controllers would be two steps away from the reference clock, or two stratum levels higher, and so on. If you are to reach five higher levels of stratum from the reference clock you could be seeing larger than normal differences between the reference clock and the clock of your domain members.

Now that we have a better understanding of how NTP and the Windows time service works, we can discuss some of what is needed for our AD monitoring solution:

- We know that NTP works over UDP port 123. AD monitoring should be checking that the port is open on Windows domain controller and member workstation firewalls, and DMZ firewalls (if required).
- The Windows Time service will need to be monitored. It should be in a running state. The default startup type will be Automatic. Since the service does not have any dependencies, we only need to ensure the service is started and in a Running state.

- The network adapters on PDC Emulators should be monitored to ensure they are communicating with domain members and other domain controllers.

In order to stay on top of time synchronization in your Active Directory environment, you should be monitoring for any instances of failures, whether it be on the domain controller or the network side. Some of the more common problems we run into on the network side would be the following:

- High volume delays on the network including high-latency wide area network (WAN) links.
- TCP/IP connectivity. This can include a gateway, other network device, or a local network card not responding.
- DNS is not working correctly.

The Netdiag.exe is the recommended utility to help troubleshoot any network issues. Another option is to turn on the Windows Time service debug log for a much more detailed look at the issue.

Now that you have learned about the inner-workings and history of NTP and the Windows Time service, let’s take next take a look at the tools used for configuration and the values that need to be monitored in your Active Directory monitoring solution in the next article: “The Active Directory Time Service - Part 2: AD Monitoring and the Event Viewer”.

 

---

Active Directory Monitoring with ENow

Active Directory as the foundation of your network, and the structure that controls access to some of the most critical resources in your organization. ENow uncovers cracks in your Active Directory that can cause a security breach or poor end user experience. In particular, ENow enables you to:

- Report on highly privileged groups (domain admins)
- AD replication errors
- Identify Expensive LDAP queries
- DNS and name resolution problems
- Troubleshoot poor Exchange performance caused by Active Directory

 

Don’t take our word for it. Start your free trial today!