Lab Objective
Configure NTP authentication on both the server and client from the earlier NTP lab, verify the client only accepts time synchronization from a server presenting the matching authentication key, and confirm an unauthenticated or mismatched NTP source is rejected entirely.
Lab Purpose
The basic NTP lab covered earlier in this series established synchronization with no authentication at all — any device claiming to be the configured server address could potentially feed a client false time information, with consequences for logging accuracy and certificate validation discussed elsewhere in this series. NTP authentication ensures a client only trusts time updates cryptographically proven to originate from the intended server.
Lab Topology
R1 (NTP server) ---- Serial0/0/0 ------ Serial0/0/0 ---- R2 (NTP client)
Same topology as the earlier NTP lab,
now with authentication addedTask 1: Configure an Authentication Key on the Server
Configure R1 with an NTP authentication key and mark it as trusted.
Task 2: Configure the Matching Key on the Client
Configure R2 with the identical key, also marked as trusted, and enable NTP authentication.
Task 3: Update the Server Reference to Require Authentication
Update R2's ntp server statement to reference the authentication key.
Task 4: Verify Authenticated Synchronization Succeeds
Confirm R2 synchronizes successfully with the authenticated key configuration.
Task 5: Introduce a Key Mismatch and Verify Synchronization Fails
Change R2's key value to a mismatched one and confirm R2 no longer trusts R1 as a valid time source.
Solution and Verification
R1(config)# ntp authentication-key 1 md5 NtpSecure2026
R1(config)# ntp trusted-key 1
R1(config)# ntp authenticate
-- "ntp authenticate" globally enables the
-- authentication check -- without this
-- command, configured keys exist but are
-- never actually enforcedR2(config)# ntp authentication-key 1 md5 NtpSecure2026
R2(config)# ntp trusted-key 1
R2(config)# ntp authenticate
R2(config)# no ntp server 10.15.15.1
R2(config)# ntp server 10.15.15.1 key 1
-- Re-adding the server statement with the
-- "key 1" clause -- without this, R2 would
-- still attempt unauthenticated NTP,
-- ignoring the trusted-key configuration
-- entirely for this particular serverR2# show ntp associations
address ref clock st when poll reach delay offset
*~10.15.15.1 127.127.1.1 3 8 64 17 4.1 0.234
-- The asterisk confirms R2 has selected
-- and is synchronized with R1 as its
-- trusted, authenticated time source
R2# show ntp status
Clock is synchronized, stratum 4
-- Successful, authenticated synchronizationR2(config)# ntp authentication-key 1 md5 WrongKey999
-- Key mismatch introduced -- R1 still
-- uses "NtpSecure2026"R2# show ntp associations
address ref clock st when poll reach delay offset
10.15.15.1 127.127.1.1 3 64 64 0 4.1 0.234
-- No asterisk -- R2 no longer trusts this
-- source, since the authentication check
-- now fails on every received packet
R2# show ntp status
Clock is unsynchronized, stratum 16
-- Stratum 16 is NTP's convention for "not
-- synchronized" -- R2 has fallen back to
-- its own free-running clock rather than
-- accepting time updates it cannot verifyKey Takeaway
NTP authentication requires three separate pieces working together: a matching key defined on both sides, that key explicitly marked as trusted with ntp trusted-key, and the global ntp authenticate command actually enabling enforcement — omitting any one of these three leaves NTP either unauthenticated or, worse, silently misconfigured in a way that looks correct in the running-config but never actually validates incoming time updates.