“What time is it?” seems like a simple question. We take for granted that a glance at our watch, computer, phone, auto dashboard or a myriad of other places will give us a “close enough” answer. What if we REALLY need to know what time it is, with a high degree of accuracy?
Most mobile phones get a signal from the carrier which is pretty good, and sometimes we can rely on our computers, but only “sometimes”. When it comes to our computer systems, many people get away with default configurations in Windows and just set the time on various bits of network gear- and it works acceptably most of the time.
Active Directory authentication works as long as the clients and servers are within a few minutes of each other, and many administrators are content with that- at least until something goes wrong and they start trying to compare logs between different systems to correlate events. Even if you are fortunate enough to have a SEIM (Security Event Information Management system) gathering all of the information for you, the time on the individual devices needs to be consistently accurate. For those situations when “close enough” isn't, and “sometimes” isn't acceptable, we need a better system of timekeeping.
Thankfully we have a variety of tools based on NTP, the Network Time Protocol to help us manage timekeeping and synchronization on our systems. The NTP folks also maintain a list of NTP servers you can use, details are at http://www.pool.ntp.org/en/. For most users, getting updates from one of the NTP pools is the best configuration. Simply select the closest regional pool from the list at http://www.pool.ntp.org/zone/@ (for the US, it would be us.pool.ntp.org), this will resolve to an up to date list of servers in your area. Simply enabling automatic time updates isn't enough, however, some thought needs to go into the hierarchy of the network. In simple networks, enabling NTP services on a perimeter device such as router or firewall is probably adequate, the device can retrieve updates from Internet servers and client systems can be configured to retrieve NTP updates from the gateway device. For a little extra redundancy, you can add Internet NTP servers as secondary time sources on your clients, but if you only have a single path to the Internet and it is down, that will not help.
For larger or more complex networks, you will need a distributed NTP infrastructure with some redundancy and fault tolerance built in. If you have multiple Internet access points, configuring routers, firewalls, or other gateway devices on each connection as both NTP clients and servers is a good first step to provide redundancy. Internal servers and network devices can then also be configured as both NTP clients and servers, retrieving updates from a list of gateway NTP servers, and answering NTP queries from client systems inside the network. At the client end of your NTP network, configure client systems to query at least two of the closest internal servers or network devices.
With this configuration, all of your systems should be synchronized and able to maintain synchronization through isolated network outages. In some situations even more may be required, dedicated NTP time sources, peering of local NTP servers, or multi-layer hierarchies, but the above should give most networks stable and reliable timekeeping. NTP is a stable and low network impact protocol, so once set up there should be very little maintenance required.
The original article/video can be found at What time is it?