Introduction

A network access migration can bring the new TACACS+ service online while routers, switches, or firewalls still send admin authentication requests to the old server. Device login works from one site but not another, command accounting still appears in the retired platform, or access breaks only after the previous AAA server is disabled because TACACS+ groups, device templates, and automation often leave old endpoints in place.

Treat this as a device AAA-routing problem instead of a generic admin access failure. Start by checking which TACACS+ server an affected network device actually contacts for authentication and accounting, because migrations often validate the new AAA platform first while field devices continue following older server groups or templates.

Symptoms

  • Network devices still authenticate admin access against the old TACACS+ server after migration
  • Command accounting or authorization logs still appear in the retired platform
  • One device group or site uses the new AAA service while another still uses the previous one
  • Device login fails only after the old TACACS+ server is shut down
  • New TACACS+ infrastructure is healthy, but affected devices never reach it
  • The issue started after moving TACACS+, AAA, or network access management infrastructure

Common Causes

  • Device AAA server groups still list the old TACACS+ host
  • Network automation templates or golden configs keep restoring the previous server settings
  • Shared secrets, source interfaces, or management VRFs were updated on one device class but not another
  • DNS or IP aliases still resolve the TACACS+ hostname to the retired server
  • Accounting and authentication paths were migrated separately, leaving part of the traffic on the old platform
  • Validation confirmed the new TACACS+ service responded but did not verify where live devices actually sent AAA requests

Step-by-Step Fix

  1. Capture one affected device and record the TACACS+ server, source interface, and AAA group it actually uses for authentication and accounting, because the runtime device path determines where admin access is validated.
  2. Compare that active AAA path with the intended post-migration design, because one stale server-group entry can keep many network devices tied to the retired platform.
  3. Review device AAA configs, automation templates, shared secrets, management VRFs, and DNS references for the old TACACS+ server, because network authentication depends on both local config and management-plane reachability.
  4. Check different vendors, device roles, and sites separately if behavior is inconsistent, because migrations often fix one template set while another still applies the previous AAA target.
  5. Update the authoritative AAA templates and device configuration so affected hardware authenticates against the intended TACACS+ service, because deploying new servers alone does not retarget already managed devices.
  6. Perform a controlled admin login test and confirm authentication and accounting reach the intended platform, because a working login does not prove the request went to the right backend.
  7. Verify the old TACACS+ server no longer receives AAA traffic from migrated devices, because split admin-auth paths can remain hidden while both systems stay online.
  8. Review fallback local login policy, clock sync, and ACLs if devices still fail to switch, because the destination can be correct while secrets or management-path controls still block the new server.
  9. Document which team owns AAA templates, network automation, and migration validation so future TACACS+ cutovers verify the actual server used by devices before retiring the previous environment.