FortiAuthenticator and Radius Admin access on Cisco SG-500X

Question

Hi All,

I was wondering if anybody had any luck configuring Radius admin authentication to the Cisco SG-500 switches, or for that matter any of their "Small-Business" line?

So far I have the switch configured as a Radius Client in FortiAuth, filtered down to a remote LDAP group. This works perfectly for allowing the login, but unfortunately the group members get privilege level 1, ie they have then elevate permissions using the Enable password.

The old FortiAuth3.3 Interoperability Guide talks about configuring the FortiAuth to send Radius Attributed of "Cisco-AVPair = shell:priv-lvl=15" and "Service-Type = NAS-Prompt-User" to elevate permissions to priv levl 15 which bypasses Enable. (pg 44 - http://docs.fortinet.com/uploaded/files/1991/fortiauthenticator-two-factor-authentication-interoperability-guide.pdf) I cannot get this to work. I have found other forum posts that state the service-type needs to be "Administrative-User" but still no dice. My concern is that a packet capture shows that the Accept-Accept packet coming back from the FortiAuth doesn't even included these Radius Attributes!

Strictly speaking, the small-business switches from Cisco are not running iOS that you would find on the Catalyst switches. In particular, I think the missing aaa authorization commands may be what I'm missing, but I'm concerned that I'm not even seeing the Radius Attributes being sent back to the Cisco Switch?

Any help would be much appreciated.

Carl_Windsor_FTNT · Accepted Answer

IIRC, the technical reason was down to how the user passwords are stored (when users are local). Admin passwords are securely hashed and not reversible which is required to support PAP used some 802.1x methods. For this reason they were precluded from being used in some methods. This limit was also applied to remote users for consistency .

I will investigate further to see if there is technical reason why this is still the case or if we can lift it and allow the required behavior.

Alex_talmage · Answer

OK so I've dug a bit further, and in the packet capture, I can see that the vendor specific attribute(26) is returning CiscoSystems. Whilst I believe full blown IOS returns just "Cisco".

My question is, is this happening because the FA is looking for a Vendor-Specfic(26) of Cisco as opposed to CiscoSystems in the Access-Request packet? See AVP from Wireshark:

Access-Request:

RADIUS Protocol Code: Access-Request (1) Packet identifier: 0x92 (146) Length: 91 Authenticator: dc040000eb67000083260000a5500000 [The response to this request is in frame 16] Attribute Value Pairs AVP: l=13 t=User-Name(1): ********** User-Name: ********** AVP: l=18 t=User-Password(2): Encrypted User-Password (encrypted): ********** AVP: l=24 t=Vendor-Specific(26) v=ciscoSystems(9) VSA: l=18 t=Cisco-AVPair(1): shell:priv-lvl=1 Cisco-AVPair: shell:priv-lvl=1 AVP: l=6 t=NAS-IP-Address(4): 0.0.0.0 NAS-IP-Address: 0.0.0.0 AVP: l=10 t=Acct-Session-Id(44): 0500009D Acct-Session-Id: 0500009D

Access-Accept:

RADIUS Protocol Code: Access-Accept (2) Packet identifier: 0x92 (146) Length: 20 Authenticator: 9f843da063da5f24b06058248e81534b [This is a response to a request in frame 15] [Time from request: 0.007331000 seconds]

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded