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-interopera...) 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.
Solved! Go to Solution.
Just in case, I tested to verify that the Attributes are being sent and they are being sent correctly (tested for User and Group Attributes in FAC 4.1.1 (0081). Note there was an issue in 4.1.0 where if an LDAP filter was used to pull users in, group attributes would not be sent. Upgrade and retry if this is the case.
Looking at the Cisco documentation for the SG-500 the correct attributes should be:
Service-Type = Administrative-User
Cisco-AVPair = "shell:priv-lvl=15"
Carl
Dr. Carl Windsor Field Chief Technology Officer Fortinet
Just tested and I know what the issue is. To get the group attributes to be sent, you have to define a filter and add the group to the filter in the RADIUS Service > Clients setting. This is deliberate as it allows you to send different group attributes depending on the Client you are authenticating to.
Try this and let me know how you get on.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
Correct. If you set a remote user a FAC Administrator, they can no longer be added to a group. You can see this if you try to add the user manually to the group; the user no longer appears in "Available LDAP users" to move across.
Carl
Dr. Carl Windsor Field Chief Technology Officer Fortinet
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.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
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]
Just in case, I tested to verify that the Attributes are being sent and they are being sent correctly (tested for User and Group Attributes in FAC 4.1.1 (0081). Note there was an issue in 4.1.0 where if an LDAP filter was used to pull users in, group attributes would not be sent. Upgrade and retry if this is the case.
Looking at the Cisco documentation for the SG-500 the correct attributes should be:
Service-Type = Administrative-User
Cisco-AVPair = "shell:priv-lvl=15"
Carl
Dr. Carl Windsor Field Chief Technology Officer Fortinet
Carl, I think you've hit the nail on the head sir. I've just confirmed those Radius Attributes work if I set up a local user. I am using a Remote LDAP Group, but the version I am running is v4.00-build0081-20160601-patch00.
I will upgrade and report back.
Thank you very much for your help!
As a workaround for the time being, I've disabled the need for an enable password on line ssh, this means that radius authenticated the login, then we have to elevate with enable but not required to enter a password. Not great, but hopefully fixed when we upgrade.
The commands on the Cisco SG500X for the workaround if running the bugged version of FAC is:
radius-server host <HostNameorIPAddress> key <shared key> usage login radius-server host source-interface vlan 50 aaa authentication login authorization SSH radius local aaa authentication enable authorization SSH none aaa authentication login Console local line ssh login authentication SSH enable authentication SSH password ****** encrypted exit line console login authentication Console password ****** encrypted
If you are on v4.00-build0081, you are already on the latest release. Let me retest with remote users and see if I can spot what is wrong here.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
Just tested and I know what the issue is. To get the group attributes to be sent, you have to define a filter and add the group to the filter in the RADIUS Service > Clients setting. This is deliberate as it allows you to send different group attributes depending on the Client you are authenticating to.
Try this and let me know how you get on.
Dr. Carl Windsor Field Chief Technology Officer Fortinet
OK I think I know what is going on now. My issue appears to be with a Remote User that I have configured as an administrator on FAC. It appears that a remote user who is configured as a FAC Administrator cannot be part of a user group?
Other accounts that are not administrators are working fine.
Although, I am using that account that is an "Administrator" to also radius login to FortiAnalyzer and FortiManager, and these Radius Clients are filtered down to the Remote LDAP group. These work perfectly, but I am not attempting to send any Radius attributes back to either of these.
Correct. If you set a remote user a FAC Administrator, they can no longer be added to a group. You can see this if you try to add the user manually to the group; the user no longer appears in "Available LDAP users" to move across.
Carl
Dr. Carl Windsor Field Chief Technology Officer Fortinet
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1740 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.