I85PREP
⌘ K
Aruba Comware Advanced study materials
Aruba Comware Advanced study resources

AAA Fallback Lockout After RADIUS Outage

Aruba Comware Advanced · Put your knowledge to work in context.

All case studies

AAA Fallback Lockout After RADIUS Outage

A switch uses RADIUS for login with a local fallback user admin. RADIUS server 10.1.1.10 is configured with radius-server timeout 5 and radius-server retransmit 2. During a WAN outage, admins cannot log in via SSH even though the local admin user exists with privilege 15. display radius scheme shows the server is 'blocked' after repeated failures. The domain is system with authentication login radius-scheme radius local. Console login with admin works. The switch also has user-interface vty 0 4 with authentication-mode scheme. After the outage, admins who were already logged in stay connected.

1. Explain why SSH fails while console local login and existing sessions work.

Read the worked answer

Diagnosis: The VTY lines use authentication-mode scheme, which routes login through the AAA domain. The domain's method list is radius-scheme radius local - RADIUS first, local second. The fallback to local only happens when RADIUS returns an authentication reject, not when the server is unreachable/blocked.

Why it fails:

  • With the server 'blocked', each SSH attempt waits timeout 5 x retransmit 2 = ~10s, then the scheme may treat it as a failure rather than a clean 'server unavailable' fallback, so the local method is not consulted (or the attempt times out at the client first).
  • Console works because console may be configured authentication-mode none or password/scheme with a different path - verify display user-interface; if console uses authentication-mode scheme too, it would also fail, so console is likely none/password or the local user is matched directly.
  • Existing sessions persist because authentication is only at session setup; an established VTY is not re-authenticated on RADIUS loss.

Key concept: radius local does not guarantee local fallback on unreachable server - behavior depends on the scheme's server-down handling and whether radius-server is marked blocked.

2. Give the configuration changes and verification to guarantee local fallback during a RADIUS outage.

Read the worked answer

Changes:

  1. Ensure the domain method list is authentication login radius-scheme radius local (already) AND that the RADIUS scheme has local fallback enabled: on Comware, the local method is only tried after RADIUS explicitly fails; to force fallback when servers are down, verify radius-server is not permanently blocked and consider radius-server test-profile/radius-server alive probes, or use authentication login radius-scheme radius local with a short timeout so unreachable servers quickly yield to local.
  2. Reduce radius-server timeout (e.g., 3) and retransmit (1) so unreachable detection is fast; the local method is then reached within acceptable time.
  3. Confirm the local user has the right service type: local-user admin class manage service-type ssh and authorization-attribute user-role network-admin (privilege 15).
  4. Keep a break-glass console with authentication-mode password and a strong local password, documented.

Verification:

  • display radius scheme - server state not 'blocked' after recovery; display domain - method list order.
  • Simulate: block RADIUS (ACL deny to 10.1.1.10) and attempt SSH as admin; should succeed via local within ~timeout window.
  • display users - confirm new sessions authenticate locally; display local-user - service-type and role correct.

Trade-off: Short RADIUS timeouts risk false fallback to local during transient latency, weakening central auth; balance timeout against WAN RTT. Document that local fallback is break-glass, not normal operation.