When authenticating via a network server, it's crucial that both the client and server have the same time. Network authentication protocols such as Kerberos and Google Authenticator require the authentication process to be short. This, in turn, requires the clocks to be synchronized. NTP is an intelligent protocol for doing this.
- [Instructor] It's important for all network-attached computers to have the same time for multiple reasons. All log messages, file accesses and logins are marked with a timestamp. Computer real-time hardware clocks, or RTCs, are built into every computer, but are only used to get the time when the computer boots up. The reason for this is that real-time clocks are inaccurate, and can lose five seconds per month, or more. Once the computer has booted up, it uses the TSC, or time stamp counter, built into the CPU, to maintain time, which is accurate, but not persistent between reboots.
Network time protocol allows our computers to access a time server on the network, and with that information, reset its local clock. These time servers are synchronized with atomic clocks around the world, an NTP server can synchronize with another NTP server. Each level away from the atomic clock is called a stratum. Stratum zero are the atomic clocks themselves, stratum one is the NTP server that synchronizes to it, stratum two is an NTP server that synchronizes with a stratum one server, and so on.
At stratum 16, the time is considered unsynchronized. Network time synchronization is important for authentication. When a user tries authenticating, the system records the timestamp. It then measures the amount of time used to authenticate. If the time was too great, authentication fails. For remote authentication sources, things are more complex. Timestamps are used in authentication protocols, such as kerberos, to prevent replay attacks, where an attacker can reuse an authentication token.
Most implementations of kerberos authentication do this. If the token is more than five minutes old authentication will fail, so it's important to have the correct time on both a client and the server. Newer versions of MIT kerberos calculate the offsets between the clocks during authentication, so the time difference is not as important. Other authentication methods, such as Google Authenticator and RSA SecurID also require synchronized clocks, and have a much tighter threshold of 30 to 60 seconds. Without synchronized time between a client's server, authentication fails.
NTP has roles, depending on the function a system provides. There are primary and secondary NTP servers, NTP peers, and NTP clients. A primary NTP server gets its time from a source such as an atomic clock, it then either provides this information to a secondary server or clients. A secondary NTP server gets its time from a primary server, and provides this information to clients either directly, or by a broadcast. An NTP peer is a host that provides time to an NTP server, and gets time from that server.
Peered hosts synchronize their time with each other. Peered hosts usually work at the same stratum level. Lastly, an NTP client only retrieves time information from an NTP primary or secondary server. A client can receive this information either by pulling an NTP server, or listening for NTP broadcasts.
- Network Time Services (NTP)
- How NTP works for authentication
- Configuring the chrony server and chrony client
- Setting up an LDAP server and LDAP client
- Creating a Kerberos database
- Configuring Kerberos client authentication