02-20-2012 01:49 AM
RADIUS authentication SF300-24P
We have just purchased 20x SF300-24P switches to be installed at our remote offices and we are unable to get RADIUS authentication to work. We already use RADIUS on all our primary network CISCO switches (e.g. 4506s¸ 3560s, 3750s, AP1231Gs,etc) and these work fine so we know the RADIUS server is working.
We are trying to use RADIUS authentication to gain management access onto these switches. Quite simply although we can see that the RADIUS server is accepting the username and password being sent, however the switch says “authentication failed” when to receives the response. We are using Microsoft NPS RADIUS Clients for authentication purposes.
We have upgrade the switches to the latest firmware 1.1.2.0, via the console it seems to have a very cut down IOS version so we cannot use the typical CISCO command set to configure the RADIUS as we normally would. Looking at the web GUI there seems to be a number of options missing including the Accounting port. When debugging is switch on there is no indication to say that any of the settings have been misconfigured.
Any advice you could offer would be gratefully received.
Mike Lewis
02-23-2012 05:59 AM
@ Randy: I did not open a case, so I have number to give you. If you do want to check further I called
00800 4414 7693 on Feb 22, 2012 at 9:02 AM GMT.
@Robert: Thanks for the link, I tried modifying my Remote Access Policy but unfortunatelly I got the same results: Connect result Unknown.
02-27-2012 12:53 AM
Whilst the screen options are slightly different for setting up MS Network Policy Server, I have been able to configure the settings correctly to enable successful authentication.
Thank you for all your help.
Mike Lewis
02-27-2012 06:52 AM
Robert
Thanks for the link.
I have received a new SG 300 today and tried to setup radius auth according to the thread you linked but am unable to authenticate.
IASLog reports an IAS_SUCCESS for the login attempts but the switch refuses access to the web interface.
The switch log gives the following replies
"%AAA-W-REJECT: New https connection, source 10.1.1.112 destination 10.1.1.119 REJECTED"
The radius authentication works with other devices (juniper router) so there shouldn't be a problem there. Running firmware
1.1.1.8
03-11-2012 07:56 AM
hi, new guy here... i have an sg300-28 with the same problem. running 1.1.2.0 switch side, and "FreeRADIUS
Version 2.1.12, for host x86_64-redhat-linux-gnu, built on Jan 15 2012 at 20:58:30". the FreeRADIUS is being backended with OpenLDAP for auth. i am using the suggested means of granting access and the RADIUS server is suppliing the following message to the switch:
Sending Access-Accept of id 0 to 192.168.254.253 port 49181
Service-Type = Administrative-User
Cisco-AVPair = "shell:priv-lvl=15"
I am unable to gain access to the switch even though authorization and authentication pass. what am i missing here?
03-19-2012 06:03 PM
no response here? am i missing something? should i have a ticket open or something? i would really like to have radius auth work as it is supposed to...
08-22-2012 05:03 AM
I managed to do a few tests using the latest Firmware release ver 1.2.7.76 which is publicly available as of 9th of August (see here: https://supportforums.cisco.com/docs/DOC-25157 ).
I am happy to report that RADIUS authentication finally works as expected!
P.S. This procedure:
https://supportforums.cisco.com/message/3568766#3568766
mentioned by Robert is correct and can work with SF300 switches with Firmware release ver 1.0.0.27 (my bad, sorry for any confusion) but the IAS logs report that the connection result is Unknown so start and stop session time are useless. You have to upgrade the firmware in order to obtain accurate logging information.
09-18-2012 08:21 AM
Hi Brendan,
what you are missing is that you probably did not try enough like I did 3 months ago when preparing switch config templates for customer deployment rollout, using 1.1.2.0 fw. It took me 1,5 days of crazy investigating what the problem with AAA could be... And then it came - I had used only the "priv15" item in Access Accept and it worked!! So simple.. Anyway, admin guide whispers something about this, unfortunately misses "only" word there.
Reading that latest 1.2.7.76 fw is again buggy more than normal, I'm much thankful that my service setup is running even with 1.1.2.0.. which I recommend to you as well.
Rregards,
Peter
09-18-2012 10:15 AM
i did have the authorization string set and the radius server was returning it to the switch, but auth still failed. with the newest firmware running on the switch now, i am able to login with my ID which is using RADIUS. i am using FreeRADIUS and the authentication goes against Kerberos (via freeradius-krb5 package) and the authorization goes against OpenLDAP, where a radiusreplyitem specifies the authorization string expected by the switch.
i have noticed that the auth is still a bit buggy. i have gone through and set the auth methods for HTTP, HTTPS, Telnet, SSH for RADIUS only. I also set Console access for RADIUS and local, with local being specified last. when i connect via minicom to the switch using the serial cable, i cannot log in with the default local ID which i did not change.
relevant config directives:
aaa authentication enable Console radius enable
aaa authentication enable SSH radius
aaa authentication enable Telnet radius
ip http authentication aaa login-authentication radius
aaa authentication login Console radius local
aaa authentication login SSH radius
aaa authentication login Telnet radius
aaa authentication dot1x default radius
am i missing something? i can post the entire "sh run" output if needed.
09-18-2012 10:44 AM
Brendan, whichever is the "top option" for the log in when you look at the gui, is what will work. So if you have Radius + local set, the Radius will work. If you move local as the top option, the local login will work but the Radius won't work. That is an expected behavior.
Dave Hornstein actually raised this issue quite a while back. He may have some further insight.
-Tom
Please rate helpful posts
09-18-2012 10:51 AM
Brendan, whichever is the "top option" for the log in when you look at the gui, is what will work. So if you have Radius + local set, the Radius will work. If you move local as the top option, the local login will work but the Radius won't work. That is an expected broken behavior.
corrected...
09-18-2012 11:03 AM
Here is the documentation excerpt-
For the RADIUS server to grant access to the web-based switch configuration
utility, the RADIUS server must return cisco-avpair = shell:priv-lvl=15.
User authentication occurs in the order that the authentication methods are
selected. If the first authentication method is not available, the next selected
method is used. For example, if the selected authentication methods are RADIUS
and Local, and all configured RADIUS servers are queried in priority order and do
not reply, the user is authenticated locally.
If an authentication method fails or the user has insufficient privilege level, the user
is denied access to the switch. In other words, if authentication fails at an
authentication method, the switch stops the authentication attempt; it does not
continue and does not attempt to use the next authentication method.
Of course the point of interest here is the second paragraph. The initial wording is the behavior you want. The second portion is very open for interpretation (I do agree it is somewhat ambiguous but consistent with the switch behavior). When I read the example and it says the Radius is busy or not responding then you will authenticate locally. Which seems fair enough. But what it doesn't say, is if you can use one or the other, but instead it seems based on preference failure.
-Tom
Please rate helpful posts
09-18-2012 11:17 AM
while i dont fully agree with the logic, i do see its reason and merits. now that i have read that help section several times over, i see what its meant to do. by requiring a failure of the auth service (not a reject of auth) to occur before descending to other auth types you avoid brute-force attacks.
09-19-2012 01:16 AM
Brendan, from what I recall we were told by the instructor at a Cisco security seminar that it is never a good idea to have RADIUS authentication as the only method because if RADIUS server fails you are effectively locked out of your devices. Using RADIUS is usually dictated by the security policy of an organization so it should be the default authentication and local authentication should be used as the fallback method and this is the logic of our current configuration.
09-19-2012 03:40 AM
Brendan,
If you indeed just send that "priv15" item only!.. you should have no issues with single AAA setup, or any combination with tt..If its about console problem, I have not tested setup of 1.AAA, 2. local.. as I use local method only for Console, and HTTP+SSH+Telnet with AAA+local. I can't help more here, I'm sorry.
09-19-2012 05:33 PM
i have the radius auth set for all access methods and the local auth for console only. my logic is that if my radius server is down, then i have more to worry about then logging into my switch. being that this is in my house, and not in a prod environment, affords me that flexibility.
the reason i called the auth logic broken was that radius returned a user not found error, not user auth failed. i am used to systems or services that differentiate between the two and continue to attempt authentication until a method returns user auth pass/fail or all methods have been attempted. i see how this is generally more processing time than say a switch might want to spend on auth, and keeping that in mind might be what i need to do. general proccessing equipment (servers, PC's, etc) dont blink when having to do this kind of stuff, but purpose built gear with less horsepower have to pick and choose their battles better, so to speak.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide