cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
21365
Views
5
Helpful
43
Replies

RADIUS authentication SF300-24P

mplewis
Level 1
Level 1

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

43 Replies 43

@ 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.

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

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

Brendan Kearney
Level 1
Level 1

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?

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...

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.

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

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.

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

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

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...

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

-Tom Please mark answered for helpful posts http://blogs.cisco.com/smallbusiness/

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.

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.

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.

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.