TACACS+ requires NTP synchronization to function reliably, but the requirement depends on how strictly your authentication server validates timestamps

TACACS+ (Terminal Access Controller Access-Control System Plus) is an authentication and authorization protocol that uses encrypted communication between network devices and a central server. When a router, switch, or firewall sends a login request to TACACS+, the server checks the timestamp on that request. If your server's clock and your device's clock are too far apart, the server rejects the request as potentially forged — even if the password is correct.

Network Time Protocol (NTP) keeps all your devices synchronized to the same time source. Without it, your TACACS+ server and your network devices drift apart by minutes or hours, and authentication fails silently. The user sees "access denied" with no clear reason why.

Key Takeaways

  • TACACS+ servers reject authentication requests when device clocks differ from the server by more than a few minutes, typically five minutes or more depending on configuration.
  • NTP synchronization prevents clock drift across your network devices and TACACS+ server, eliminating a common cause of unexplained authentication failures.
  • You can check clock synchronization by comparing the time shown on your device's CLI with the time on your TACACS+ server, or by enabling debug logging on the TACACS+ daemon.
  • If NTP is not running, manual time synchronization is a temporary workaround but will fail again as clocks drift, usually within hours or days depending on hardware.
  • Most TACACS+ implementations allow you to adjust or disable timestamp validation, but this weakens security and is not recommended for production networks.

How TACACS+ timestamp validation works

When a network device sends a TACACS+ authentication request, it includes a timestamp generated from its local clock. The TACACS+ server receives the request, extracts the timestamp, and compares it to the server's current time. If the difference exceeds the configured threshold — typically 300 seconds (5 minutes) — the server discards the request without processing it.

This validation exists to prevent replay attacks, where an attacker captures an old authentication request and resends it later to gain access. A timestamp tells the server whether the request is fresh or stale. Without timestamp checking, an attacker could replay a captured request from weeks ago and potentially succeed if the password hasn't changed.

The problem is that this security feature becomes a denial-of-service vector if your clocks are not synchronized. A device with a clock 10 minutes ahead of the server will have every request rejected, even with correct credentials.

Clock drift and why it happens without NTP

Every device has an internal clock that runs at a slightly different rate. A router's clock might lose 2 seconds per day; a switch's clock might gain 3 seconds per day. Over a week, these small differences add up to minutes. Without NTP, you have no way to correct these drifts automatically.

When you manually set the time on a device using the CLI, that clock starts drifting again immediately. Within 24 to 48 hours on older hardware, or within days on newer hardware, the clock will be noticeably off. If your TACACS+ server is also not synchronized, the two clocks drift in opposite directions, and the gap widens faster.

Some devices allow you to set the clock to sync with an external source at boot time, but this only helps if the device reboots regularly. Most network equipment runs for months or years without a restart, so a one-time sync at boot is insufficient.

Checking whether your clocks are synchronized

The simplest check is to compare the time displayed on your device with the time on your TACACS+ server. Log into a router or switch and run the command to display the current time — on Cisco devices, this is show clock. Then log into your TACACS+ server and run date (on Linux) or check the system clock in Windows. If the times differ by more than a few minutes, you have found your problem.

A more detailed check is to enable debug logging on your TACACS+ daemon. On Linux systems running tac_plus (the open-source TACACS+ server), you can run the daemon in debug mode to see exactly why requests are being rejected. The log will show "timestamp out of range" or similar messages if clock drift is the culprit. On commercial TACACS+ servers like Cisco ACS or Cisco ISE, check the authentication failure logs for timestamp-related errors.

You can also use NTP diagnostic tools to check synchronization status. The command ntpstat on Linux shows whether NTP is synchronized and how far off the local clock is. On Windows, w32tm /query /status shows NTP status and offset.

Setting up NTP to keep clocks in sync

NTP works by having all devices contact a time server (or a hierarchy of time servers) and adjust their clocks to match. Most networks use public NTP servers like pool.ntp.org, or they run their own internal NTP server that syncs to a public source.

To enable NTP on a Cisco router, you configure it to contact an NTP server and then enable NTP on each interface. The configuration looks like this: you specify the NTP server address with the ntp server command, then enable NTP on the management interface with ntp enable. The device will then contact that server every few minutes and adjust its clock as needed.

On a Linux TACACS+ server, you install and start the NTP daemon (usually ntpd or chrony on modern systems). The daemon reads a configuration file that lists NTP servers to contact, and it runs continuously in the background, keeping the system clock synchronized.

Once NTP is running on all your devices and your TACACS+ server, the clocks stay within a few milliseconds of each other. TACACS+ authentication requests will no longer be rejected due to timestamp mismatches.

What to do if NTP is not available or not running yet

If you cannot set up NTP immediately, you can manually synchronize the clocks as a temporary measure. Log into each device and set the time to match your TACACS+ server's time. Use the clock set command on routers and switches, or the date command on Linux servers.

This workaround buys you time — usually 24 to 72 hours depending on hardware — before clocks drift far enough to cause authentication failures again. It is not a permanent solution because the clocks will drift apart again, and you will be back to unexplained authentication failures.

If you are in a situation where NTP cannot be deployed (for example, devices on an isolated network with no external time source), you can adjust the TACACS+ server's timestamp tolerance. Most TACACS+ implementations allow you to increase the acceptable time window from the default 5 minutes to 10, 15, or even 30 minutes. This reduces security slightly — a replay attack window becomes larger — but it makes the system more forgiving of clock drift. This is a trade-off to consider only if NTP is truly unavailable.

TACACS+ implementations that are less strict about timestamps

Not all TACACS+ servers validate timestamps equally. Some commercial implementations like Cisco ISE allow you to disable timestamp checking entirely, though this is not recommended. Open-source implementations like tac_plus have configurable tolerance windows. Some older or simpler TACACS+ servers may not check timestamps at all, which means they will work without NTP but at the cost of weaker security.

Before assuming your TACACS+ server does not need NTP, check the documentation for your specific implementation. If you are using Cisco ACS, Cisco ISE, or a vendor-specific TACACS+ solution, look for settings related to "timestamp validation," "time tolerance," or "replay protection." If you are running an open-source server, check the configuration file for similar options.

Even if your TACACS+ server is lenient about timestamps, NTP is still a best practice for network administration. Accurate time is needed for log correlation, security event analysis, and compliance auditing. If you have TACACS+ running, you should have NTP running as well.

Frequently Asked Questions

What happens if my device's clock is ahead of the TACACS+ server?

The server rejects the request as invalid, just as it would if the clock were behind. The direction does not matter — only the magnitude of the difference. A device 10 minutes ahead will fail just as reliably as a device 10 minutes behind.

Can I use a single NTP server for my whole network?

Yes, but it is not ideal. A single NTP server is a single point of failure — if it goes down, your devices stop synchronizing and clocks drift again. Most networks use at least three NTP servers so that devices can reach consensus on the correct time even if one server is unavailable.

How often does NTP update the clock on my device?

NTP typically checks and updates the clock every 64 to 1024 seconds (roughly every 10 to 17 minutes) once synchronization is established. The exact interval depends on the NTP implementation and configuration. This is frequent enough to keep clocks within milliseconds of each other.

Will TACACS+ work if my device and server are off by just one minute?

It depends on the server configuration. Most TACACS+ servers use a default tolerance of 5 minutes, so a 1-minute difference is acceptable. However, if the tolerance is set lower (some implementations allow 1-minute or 2-minute windows), a 1-minute difference could cause failures. Check your server's configuration to be sure.

Is NTP a security risk if I use public NTP servers?

Public NTP servers are generally safe to use for time synchronization. NTP has built-in authentication mechanisms, and the protocol is designed to be resilient to tampering. However, if you are in a highly secure environment, you can run your own internal NTP server that syncs to a public source but only accepts NTP requests from your internal network.