Nexus 5K and 7K RADIUS Authorization with Steel Belted RADIUS

ieffinger · ‎02-22-2010

I am attempting to provide very basic authorization via Steel Belted RADIUS for a Nexus deployment.

Here is the code from the Nexus:

radius-server host [server] key [key]
radius-server host [server] key [key]

ip radius source-interface mgmt0

aaa group server radius GEN_AAA
    server [server]
    server [server]
    use-vrf management
    source-interface mgmt0

aaa authentication login default group GEN_AAA
aaa authentication login console group GEN_AAA
aaa accounting default group GEN_AAA
aaa authentication login error-enable

On the Steel Belted RADIUS server the client is setup as a basic IOS 11.1 or later (Nexus is not an option). The group setup for the relevant user group has a return code of:

shell:roles*"network-admin"

shell:priv-lvl=15

When I authenticate from a Catalyst 6509 with IOS 12.2 the authorization based on the shell:priv-lvl works fine. Only those users in the 'special' group have admin (lvl 15) access.

With the Nexus gear I authenticate fine but the RADIUS user is always put in the network-operator role (default) regardless of the 'special' group shell:roles*"network-admin" return code defined.

In other words it seems to work fine for IOS devices (Catalyst 6500 and 3750E so far) but not at all for Nexus gear. Unfortunately I am not in a position to suggest and implement ACS or another AAA server that supports TACACS.

Is there any way to pull this off with SBR?

Any help is much appreciated.

khwajanusrat · ‎02-23-2010

I see you have 'aaa authorization ..' commands missing.

ieffinger · ‎02-23-2010

Hello Nusrat,

I appreciate the pointer. If I was using TACACS for AAA, authorization sets would be a consideration. However, authorization is not permitted when using RADIUS for AAA on the Nexus platform.

In any case I was able to resolve the issue with the assistance of the customer and their support contact at Juniper. For the VSA feature to begin working a change to the INI file and a restart of the SBR services was required. Placing the desired group of users in the network-admin group is functioning as desired.

NOTE:

In addition to the configuration in the original post the following should be added to stop any 'standard' users defined on the SBR server from logging in with network-operator privileges:

no aaa user default-role

If no role is provided from the RADIUS server via the Cisco-AVPAIR VSA (ex. Cisco-AVPAIR = shell:roles*network-admin) by default a Nexus box places the user in the network-operator role. This role has complete read access on the system allowing, among other things, a read view of the configuration. The above command stops any role mapping resulting in non-configured users / groups on the RADIUS box not being able to log in period.

rthakker · ‎01-11-2012

Hello Jeff

Did you manage to resolve this issue?

I am currently working to implement Nexus 5k and 3k with SBR and come accross your post so I am wondering do I need to still worry about this or not?

Your help is much appriciated.

Thanks

Ritesh