This alert indicates that the server’s clock is not synchronized with the international NIST-F1 official standard.
This condition may have different causes and outcomes. For example, when two or more computers are running replicating databases, if their clocks are not synchronized properly, important SQL functions such as rollbacks and saves may fail with possible data corruption or loss.
In many cases, server time sync issues stem from the Kerberos protocol, which has a security feature that looks at the time stamp on Kerberos tickets in an effort to prevent them from being reused. A ticket is rejected if it is more than five minutes old. Therefore, if the clocks fall out of sync by more than five minutes, Kerberos will begin to break down.
Normally, time synchronization doesn’t pose a problem where the same NTP (Network Time Protocol) is used across the whole range, but in mixed local/cloud environments, this may not be possible. Where some production servers are virtualized or cloud-based, clock synchronization can become an issue, also where multiple Active Directory forests exist.
Find out how you can save hours of work when investigating the root cause of this issue.
Symptoms :
Two or more servers report different clock times.
Impact: High
Proper time synchronization is important to maintain data integrity- when there is no synchronization, data updates may be out of order or inconsistent. Inaccurate timestamps can lead to compliance violations. It might affect business flow when it’s important to track time changes precisely.
Expected behavior :
The server clock must be synchronized with the international NIST-F1 official standard.
Possible causes:
1- Unreliable Time Sources or errors. Priority: High
Unreliable or incorrect time sources for synchronization can lead to inaccurate time displayed.
Problem identification:
Identify a server that is configured by an inaccurate time source.
Choose time sources that are widely recognized and compare them to the server’s current time and date. You should track each server clock manually. Otherwise, you would not know this issue even exists.
AimBetter sends a notification that the server clock is not synchronized.
While this issue persists, notifications will continue to be sent until the server administrator corrects the clock synchronization.
Recommended action :
Adjust the proper time and date to the server, comparing it to the NIST-F1 official standard or similar trusted time sources.
2- Connection issues and latency. Priority: Medium
When there are connection issues or high latency in the network between the server and the NTP server, it might cause delays in time synchronization. That’s relevant if the server uses the Network Time Protocol for clock synchronization.
High latency can result in an inaccurate round-trip time. As a result, there’s a possibility for the clock’s loss of synchronization. Packet loss might disrupt the synchronization as well.
Problem identification:
Identify clock synchronization problems in parallel to packet loss or latency in the network.
- Using a network monitoring tool, you should check how much traffic flows through your network. Take into account that most monitoring tools help pinpoint when a problem starts, with which you can’t compare time frames.
- After identifying times of clock not synchronized, measure the amount of bandwidth being used during data transfer. When it’s large, it might cause packet loss.
- Review your network logs to see if there are any unusual patterns. This might take considerable time.
With AimBetter an immediate notification is sent once there is a network problem, and easily see what happened in parallel to this event.
Recommended action :
If possible, move high-volume traffic (e.g., remote storage, backups) onto a secondary network or reschedule to periods of low SQL demand.
In addition, you should increase the network bandwidth and correction mechanisms to minimize changes for higher latency, causing the server’s clock to be not synchronized.
3- Kerberos protocol errors. Priority: Medium
Kerberos is a network authentication protocol that is designed to provide secure authentication for users and services. The protocol relies on synchronized clocks, which means that Kerberos raises errors when clocks are unsynchronized.
For example, when a user requests a ticket from the TGS, the TGS includes an expiration time in the ticket, indicating when it was issued and when it expires. The ticket needs to be presented to the target before the expiration time, or else it becomes invalid since the servers’ clocks are unsynchronized.
Problem identification:
Identify authentication logs and messages related to Kerberos errors.
- Review the authentication logs on both the client and the server. In the logs, look for warnings and errors related to expired tickets.
- Verify the clock synchronization status of the relevant servers and clients. Use a tool like Network Time Protocol (NTP) to ensure it.
- Check the Windows Event Viewer for errors.
When there are clock unsynchronized issues in parallel to Kerberos errors, the data is displayed in a user-friendly interface, and notifications are sent in order to alert about this situation.
Recommended action :
Examine the error messages in order to address the required solutions.
Ensure that all entities (the client, the authentication server -AS, and the ticket-granting server -TGS) involved in a Kerberos authentication process have synchronized clocks.