Introduction

An identity or network access migration can move authentication services successfully while VPN appliances, switches, wireless controllers, or firewalls still send RADIUS requests to the old server. Users fail to connect, policy enforcement becomes inconsistent, or one device group authenticates correctly while another still depends on the retired AAA platform because network access infrastructure often keeps its own server list and shared secret configuration.

Treat this as a network-auth path problem instead of a generic directory outage. Start by checking which RADIUS server the affected device actually contacts during login, because migrations often update directory services and identity policies first while access devices continue using the previous AAA target.

Symptoms

  • VPN, Wi-Fi, or device login authentication still hits the old RADIUS server after migration
  • Some network devices authenticate correctly while others fail or use the retired platform
  • Access policies differ by location, controller, or NAS device after cutover
  • Authentication logs in the new platform stay empty even though users are still attempting to connect
  • Requests reach the old server until it is shut down, then logins begin failing completely
  • The issue started after moving RADIUS, NAC, VPN, or directory-backed network authentication services

Common Causes

  • The NAS device, controller, or firewall still lists the old RADIUS hostname or IP as its AAA server
  • Shared secrets were updated on the new platform, but network devices still use the secret paired with the old server
  • A server group, failover order, or policy set still prioritizes the retired RADIUS target
  • One site or controller template was migrated while another still uses the old AAA configuration
  • DNS aliases, load balancers, or source-interface settings still direct requests to the previous environment
  • Validation confirmed user identities in the new platform but did not test real RADIUS requests from each access path

Step-by-Step Fix

  1. Capture one failed or inconsistent authentication attempt and record which NAS device, source IP, and RADIUS server handled it, because the live AAA path matters more than the migration diagram.
  2. Compare that active RADIUS target with the intended post-migration authentication service, because one stale server entry or failover group can keep a device fleet tied to the retired platform.
  3. Review AAA server definitions, RADIUS server groups, shared secrets, controller templates, and policy mappings on affected network devices for references to the old environment, because RADIUS settings often live on every access device.
  4. Check failover ordering, health checks, and load-balancer targets if some requests still land on the old server, because partial migration drift often hides behind redundancy logic.
  5. Update the authoritative RADIUS server settings and push the new config to the affected devices, because changing the identity platform does not automatically retarget network hardware.
  6. Trigger a controlled authentication test from each affected access path and confirm the intended RADIUS platform logs and authorizes the request, because success for one device does not prove the whole fleet moved.
  7. Verify the old RADIUS server no longer receives authentication traffic, because split AAA routing can leave policy and audit behavior inconsistent across sites.
  8. Review authorization rules, VLAN assignment, MFA prompts, and accounting if authentication succeeds but access behavior still differs, because migrations often fix the server endpoint before aligning policy logic.
  9. Document which team owns AAA device templates, shared secrets, and post-cutover validation so future identity migrations test real network access flows before decommissioning the old platform.