cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5910
Views
18
Helpful
14
Replies

RADIUS Authorization not working for Nortel Switches through ACS 5.3

Akhtar Samo
Level 1
Level 1

Hello,

RADIUS authorization is not working on Nortel Switches, I have configured the relevant access policies for the RADIUS attributes (snapshot attached)

Command not getting executed because of authorization failure:

config cli password rwa

I also don't see RADIUS authorization reports option, just checking if someone has figured out how to configure these reports ?

I did a packet capture for the AAA packets from the nortel switch and found that the accounting request contains the cli command sent for authorization. (pcap file attached)

Regards,

Akhtar

1 Accepted Solution

Accepted Solutions

Akhtar,

That is not how radius authorization works. The access accept and the av-pairs that are sent in the response is the authorization for that user's session. This isnt like tacacs where every command is authorized with a seperate authentication request with the command the client is running.

When it comes to radius accounting that is too late in the process.

Thanks,

Tarik admani

View solution in original post

14 Replies 14

Tarik Admani
VIP Alumni
VIP Alumni

Akhtar,

I wanted to know where you got these radius attributes from, it seems as if you are passing read only permissions to the end user.

Thanks

Tarik admani

Tarik,

I got it from the Nortel vendor. What we are trying to do is to allow read-only users to change the user password using the command 'config cli password rwa'

Regards,

Akhtar

Akhtar,

What you want to do at this point is to verify if the radius attributes are entered properly. I checked google and couldnt find these in any of the nortel radius dictionaries. Also based on the pcap the access-accept is sending the first attribute only and not the other 2 listed below in your screenshot (see packet 2).

If you ssh into the ACS you can enable debugs by following these commands after you authenticate: acs-config > (wait 45 seconds)> enter you superadmin (web [not cli] credentials) > debug-log runtime level debug > exit > exit

Then reproduce the error and log the timestamp of when the attempt was made. Then you will take a support bundle and post the acsRuntime.log file that has the timestamp of when the event took place. Either you can post them here or have Cisco TAC help find the root cause.

It doesnt make sense as to why only one of the attributes are being sent back hopefully the debugs will shed some light.

Thanks

Tarik Admani

Tarik,

What you want to do at this point is to verify if the radius attributes are entered properly. I checked google and couldnt find these in any of the nortel radius dictionaries. Also based on the pcap the access-accept is sending the first attribute only and not the other 2 listed below in your screenshot (see packet 2).

I am checking if we can put exact attribute names and IDs. Dont you think that packet2 should only contain the first attribute because it is just the authentication response and the Accounting requests and response is containing the rest of the authorization attributes (packet 5)

Debug is the last action we have planned since the customer is reluctant in running that. I am trying to ensure that the configuration is up to the mark before we go for the debug.

Akhtar,

That is not how radius authorization works. The access accept and the av-pairs that are sent in the response is the authorization for that user's session. This isnt like tacacs where every command is authorized with a seperate authentication request with the command the client is running.

When it comes to radius accounting that is too late in the process.

Thanks,

Tarik admani

Tarik,

Thanks for your interest in this case. There is slight improvement in the packet capture pattern, now we are able to see the attributes in the access-accept packet (file: parameter_match_28-June-2012.enc), this was achieved after prioritizing the profile, but still the command doesn't work.

These are the updated attributes configured in the ACS policy

AttributeID
ERS_8XXX_CLI_Commands195
ERS_8XXX_Command_Access194
Passport-Access-Priority192

I requested the nortel vendor to send us a working pcap from their lab setup which might be from a different RADIUS server (file:radius_working_lab_pkt_cap.cap), I see that the 2nd packet is completely matching with ours

(file: parameter_match_28-June-2012.enc) but the difference is just in the sequence of of attributes which shouldn't matter and the other difference is accounting packets which are not there in the lab setup pcaps.

Regards,

Akhtar

Hi Akhtar

 

We were trying to do the do ACS authentication for Nortel devices with one set of users for FULL access and another set of users for READ-ONLY access. From the post I can understand you already have worked  on this scenario.Can you please help me to share the attributes which you have used for achieving the Read-Only authentication access to the Nortel switches. 

Thanks in advance

Sanish

 

You need to contact Nortel and ask them for the dictionary file of the radius attributes to be used for this kind of integration.

They should have certain document that shows you the attribute needed for differentiated level of Access.

If you can get these info we can help you promptly.

The attributes given by them are following and same has been added to the ACS 5.3 RADIUS VSA dictionary

AttributeID
ERS_8XXX_CLI_Commands193
ERS_8XXX_Command_Access194
Passport-Access-Priority192

If you have a look at the pcap files attached (RADIUS-Accounting-Request-pcap2.JPG), I see that the attribute name is not matching with the name added into the dictionary t=Unknown-Atribute(193) but the attribute ID is matching which is 193

Also have a look at the (RADIUS-Access-Accept-pcap1.JPG) this time you will see that the RADIUS authentication request is matching the attribute name and IDs both (t=Passport-Access-Priority(192))

Do you think that the Attribute Names sent by the Nortel Switch should also match with the one in the ACS RADIUS Dictionary ?

Akhtar,

Do not worry about the unknown attribute, that is just wireshark displaying its message since this is vendor specific and it doesnt have the dictionary to reference the av-pair. You may need to get something official from the Nortel support team or provide us with a link to help troubleshoot this issue a little deeper.

Thanks

Tarik Admani

Akhtar,

I looked at the pcap and now that it matches the lab capture that the vendor provided you I think it is safe to remove the ACS from this piece of the configuration and start to compare the switch code to what they vendor is running in their lab scenario.

Also are you allowing command authorizatoin on the Notel switch, i know on cisco switches if you want to authorize commands you have to add those to the configuration in order for it be allowed.

I will start with the AAA specific commands and make sure that there isnt anything you are mssing and also look at the debugs on both devices too, it could very well be that the av-pairs are out of order but I would get as close to the lab pcap as possible to rule out anything odd like that.

Thanks

tarik Admani

Further testings showed us that command authorization works when the switch is accessed through telnet but not with SSH, so finally the problem has been isolated to the switch. I will send the final post on the fix for this problem on the switch so that others dont face these issues.

Akhtar,

I am glad you are getting this sorted out. Please let us know and always please leave rate any helpful feedback.

Thanks,

Tarik Admani

Hi Tarik,

There was a bug on the Nortel Switch which restricts RADIUS authorization through SSH but not through telnet. Thanks for your help and support.

Regards,

Akhtar