RADIUS Reject vs No Response: When Local Login Runs

Keeping an emergency local account does not make it a second chance for every rejected login. In the Cisco IOS and IOS XE AAA model, that database is consulted only when the earlier method fails in a specific way, and a RADIUS server answering with a rejection has not failed that way. The local account covers an unreachable method, not a refused one. Believing otherwise turns a policy decision into a hunt for a server fault that does not exist.

Why the method list looks like a ladder

A line such as aaa authentication login default group radius local reads left to right, and most people read it as try RADIUS, then try the local database. The syntax invites that reading because a list is a sequence. The semantics are narrower: the list names authentication methods, and the rule for advancing from one to the next depends on the result of the previous method rather than on giving the user another attempt.

A method that returns an error and a method that returns a failure lead to different outcomes here. Denial is an answer, because the server processed the credentials and said no, and the list stops there. An unreachable server, an expired request or a reply that cannot be validated is the case that lets the next method run, and only where the platform's failure handling is configured that way. That is why the classic advice to append local works for outages and does nothing for wrong passwords. Read the list as two questions instead: which method answers, and what the platform counts as an answer.

Separate the method list from the server group

The method list is one layer and the server group is another. The keyword group radius names a group whose internal order, retries, timeouts and dead-server detection belong to the group, while a local method is a layer above it. Tuning anything inside the group therefore cannot turn a rejection into a fallback. Confirm which list the service actually references before changing either layer.

Print the AAA configuration and read the list the service points at, not the default you remember writing. Do it from the device the service actually terminates on.

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

The server table reports each entry's state and counters, which tells you whether the gateway reached the server during the attempt. A server marked up with a rising request count has been answering, so the failed login is a decision rather than a connectivity problem.

Read the reply before you read the log

The reply code names the outcome and implies its own next step. Access-Reject means the backend made a decision, so the useful evidence is the policy that matched and the account state behind it. Access-Challenge means the exchange wants another supported step such as a second factor, and local fallback would quietly skip something the policy requires.

Reproduce one attempt with a designated test account so the reply and the backend record can be compared at the same timestamp. Use a credential you are allowed to fail.

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

A missing or unrecognized RADIUS client entry is a common cause of a silent timeout, because the server receives the request, finds no matching client definition and drops it without answering. A shared-secret mismatch usually looks like a timeout as well, since the reply fails validation and is discarded. Neither of those looks like Access-Reject, and neither is repaired by adding a local account. Check the client definition and the secret on both sides before you touch the method list.

Why the local account never proved anything

An account that sits after a group in the list proves only that someone planned for an outage. It says nothing about whether the plan works, because the case that exercises it is the case nobody rehearses: the server stopped answering. A local login that is never reached in normal operation can carry an expired password or a locked state for months without anyone noticing.

Emergency access is a design decision, not a configuration side effect. Give it its own restricted account, its own owner and a written recovery procedure, and fold shared-secret rotation into that procedure. Keeping an identically named local password for every central user is the pattern that quietly reintroduces the access you thought you had removed.

The test that matters is deliberate, and it will interrupt logins while it runs. That is exactly why it belongs in a scheduled window with the rollback step written first.

Check the fallback path during a maintenance window

Sequence the test so you never remove the last way in. Confirm an independent management path first, then normal permitted access, then a deliberate denial, then the approved outage behaviour. Those four cases have different expected results, and collapsing them into one test is how people lock themselves out of a device they still need.

Run every check from a console session or an out-of-band path, so a mistake cannot close the session you are working in. The console is the one path that does not depend on the component under test.

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

Afterwards, restore the previous configuration and confirm the counters move again on the next real login. If the deliberate denial produces a local login instead of a rejection, then the list or the failure handling is not what you believed, and that finding outranks the outage you started with. Write the result into the change record next to the account names and the date of the test.