RADIUS AAA Configuration Questions

Hello, I am running into some issues getting RADIUS AAA working. I am using a Windows NPS server for RADIUS. I only need to setup a Admin access to this switch. A read-only/monitor profile is not needed.

I can see my authentication attempts being granted on the NPS server. With the correct policy being hit but I am never granted access to the switch. Do I need to send a specific VSA back to the switch to map user roles? I currently am not sending a VSA back to the switch from the RADIUS server.

The one thing that confused me in the Mellanox documentation is the: “aaa authorization map” command. Is this needed for successful authentication? I attempted to add “aaa authorization map default-user admin” however there was no change in behavior.

Current config is very basic:

aaa authentication login default local radius

radius-server host

radius-server host key ********

Any help would be greatly appreciated.


Hi Kevin,

You need to be sure you set the aaa authorization map order to tell it to check the RADIUS server first.

(config) # aaa authorization map order remote-first

From the User Manual, this command does the following:

Sets the user mapping behavior when authenticating users via RADIUS

or TACACS+ or LDAP to one of three choices. The order determines

how the remote user mapping behaves. If the authenticated username

is valid locally, no mapping is performed. The setting has the following

three possible behaviors:

local-only – maps all remote users to the user specified by

the command “aaa authorization map default-user <user

name>”. Any vendor attributes received by an authentication

server are ignored.

remote-first – if a local-user mapping attribute is returned

and it is a valid local username, it maps the authenticated

user to the local user specified in the attribute. Otherwise, it

uses the user specified by the default-user command.

remote-only – maps a remote authenticated user if the

authentication server sends a local-user mapping attribute.

If the attribute does not specify a valid local user, no further

mapping is tried.

Some helpful commands on the switch:

show radius <<<----show radius server configuration on switch

show aaa <<<<-----shows default user

show usernames <<<<----shows usernames configured locally on switc

show users <<<-----shows which host is currently connected to

show aaa authentication attempts <<<----shows information on current and past login attempts as well as configuration



Hi Kevin,

I just hit the same issue and the solution was to change the aaa method order :

aaa authentication login default local radius

replace with

aaa authentication login default radius local

As far as the radius servers are accessible, they will do the authentication. The drawback of that is that the second method (local) is not tried if the radius servers are up and running.

This is a bit silly : there is no means to have the second method tried if the user account is not found on the first method listed (radius). The second method is only tried if all the radius servers fail.

Also this imply that when you configure “aaa authentication login default local radius”, the radius method is never attempted because the local method may not fail…

I hope this will be addressed on a futur Onyx release.