06-24-2012 04:20 AM - edited 03-10-2019 07:13 PM
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
Solved! Go to Solution.
06-26-2012 06:40 AM
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
06-24-2012 02:09 PM
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
06-24-2012 11:56 PM
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
06-25-2012 12:05 AM
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
06-26-2012 06:03 AM
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.
06-26-2012 06:40 AM
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
06-28-2012 03:37 AM
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
Attribute | ID |
ERS_8XXX_CLI_Commands | 195 |
ERS_8XXX_Command_Access | 194 |
Passport-Access-Priority | 192 |
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
10-06-2015 04:08 AM
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
06-25-2012 10:48 AM
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.
06-26-2012 05:31 AM
The attributes given by them are following and same has been added to the ACS 5.3 RADIUS VSA dictionary
Attribute | ID |
ERS_8XXX_CLI_Commands | 193 |
ERS_8XXX_Command_Access | 194 |
Passport-Access-Priority | 192 |
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 ?
06-26-2012 06:43 AM
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
07-01-2012 11:35 PM
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
07-05-2012 05:30 AM
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.
07-05-2012 07:41 AM
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
07-13-2012 05:35 AM
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
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