Ack. But please make sure to define appropriate fallback methods. So
in your case, I would replace aaa authorization exec default group
radius local
by
aaa authorization exec default group radius if-authenticated
I.e. when Radius is not available, authorization succeeds if the user
has authenticated.
I'll test this, but my impression was that with the local on the end,
when radius is unavailable, locally defined usernames are used and the
enable secret is still used when enabling from an exec level local
user.
Don't confuse authorization with authentication. Let's make a more
sophisticated example:
username foo privilege 15 password bar
!
aaa authen login default group radius local
aaa authorization exec default group radius local
if radius is unavailable and you log in with user "foo" and correct
password, the exec session will be privileged as exec authorization also
falls back to "local".
username foo privilege 15 password bar
!
aaa authen login default group radius local
aaa authorization exec default group radius if-authenticated
In this case, "privilege 15" will be ignored if radius server is
unavailable (due to "if-authenticated" fallback method) and your shell
is unprivileged.
oli
10 messages in net.nether.puck.cisco-nsp[c-nsp] aaa different for console log...
