Hi all, there are inquiries every once in a while here about how to enable command authorization for Cisco devices in a Cisco-AVPair. The usual answer is: find out if the NAS has an attribute for it. Now I'm myself trying to get rid of a haunting daemon, the tac_plus daemon, and so I investigated. Cisco claims that there is a complete mapping scheme to translate TACACS+ expressions into Cisco-AVPair Vendor-Specific. This works for example with the priv-lvl attribute: cisco-avpair = "shell:priv-lvl=15" There is a web page for Cisco IOS at http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chap... detailing which TACACS+ commands exist, and it suggests that cisco-avpair = "shell:cmd=show" would do the trick to authorize the "show" command. EXCEPT that there is a tiny note for the commands "cmd" and "cmd-arg" saying that they cannot be used for encapsulation in the Vendor-Specific space. These two are the ONLY ones. Since it's just about parsing the string content of cisco-avpair at the router side, there is absolutely no technical reason why these two wouldn't go through. The only explanation then is that this is a deliberate step by Cisco to make sure that TACACS+ is "superior" to RADIUS by arbitrarily cutting down functionality. Probably the code in IOS is larger with an exception handling to make sure that it doesn't work. I must say: I'm pissed. But I hope I could at least clarify this topic. My next-best approach to circumvent this would be to define an intermediate privilege level that only has the permission to do the commands in question, and only assign the users in question to that lower priv-level. Scales poorly, but enough for us. Maybe that approach serves some others as well. Stefan Winter -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
Hi all,
there are inquiries every once in a while here about how to enable command authorization for Cisco devices in a Cisco-AVPair. The usual answer is: find out if the NAS has an attribute for it.
Now I'm myself trying to get rid of a haunting daemon, the tac_plus daemon, and so I investigated. Cisco claims that there is a complete mapping scheme to translate TACACS+ expressions into Cisco-AVPair Vendor-Specific. This works for example with the priv-lvl attribute:
cisco-avpair = "shell:priv-lvl=15"
There is a web page for Cisco IOS at http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chap... detailing which TACACS+ commands exist, and it suggests that
cisco-avpair = "shell:cmd=show"
would do the trick to authorize the "show" command. EXCEPT that there is a tiny note for the commands "cmd" and "cmd-arg" saying that they cannot be used for encapsulation in the Vendor-Specific space.
These two are the ONLY ones. Since it's just about parsing the string content of cisco-avpair at the router side, there is absolutely no technical reason why these two wouldn't go through. The only explanation then is that this is a deliberate step by Cisco to make sure that TACACS+ is "superior" to RADIUS by arbitrarily cutting down functionality. Probably the code in IOS is larger with an exception handling to make sure that it doesn't work.
I must say: I'm pissed. But I hope I could at least clarify this topic.
My next-best approach to circumvent this would be to define an intermediate privilege level that only has the permission to do the commands in question, and only assign the users in question to that lower priv-level. Scales poorly, but enough for us. Maybe that approach serves some others as well.
Stefan Winter
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Could you add this to the wiki ?
http://wiki.freeradius.org/Cisco I myself don't use any Cisco kit, but the situation is much the same with HP Procurve Switches. On all but the most expensive switches TACACS+ is the only way to define command lists, on all the others your either a manager or an operator. HP Claim to support a few VSA's for setting command lists and priv levels, but on most of their switches they don't actually work ! -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Could you add this to the wiki ?
Done.
I myself don't use any Cisco kit, but the situation is much the same with HP Procurve Switches. On all but the most expensive switches TACACS+ is the only way to define command lists, on all the others your either a manager or an operator. HP Claim to support a few VSA's for setting command lists and priv levels, but on most of their switches they don't actually work !
Amazing. I would have thought TACACS+ is totally dead and only Cisco holds up their flag. Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Hi Stefan, It may be primarily Cisco that pushes TACACS+ because ACS is a much better TACACS+ server than it is a RADIUS server. However, there are many vendors that offer some degree of support for TACACS+ just to avoid one of the barriers to entering the many Cisco only networks. :-) Rgds, Guy On 07/01/2008, Stefan Winter <stefan.winter@restena.lu> wrote:
Could you add this to the wiki ?
Done.
I myself don't use any Cisco kit, but the situation is much the same with HP Procurve Switches. On all but the most expensive switches TACACS+ is the only way to define command lists, on all the others your either a manager or an operator. HP Claim to support a few VSA's for setting command lists and priv levels, but on most of their switches they don't actually work !
Amazing. I would have thought TACACS+ is totally dead and only Cisco holds up their flag.
Stefan
-- Stefan WINTER
Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung
6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Stefan Winter wrote: ...
These two are the ONLY ones. Since it's just about parsing the string content of cisco-avpair at the router side, there is absolutely no technical reason why these two wouldn't go through. The only explanation then is that this is a deliberate step by Cisco to make sure that TACACS+ is "superior" to RADIUS by arbitrarily cutting down functionality. Probably the code in IOS is larger with an exception handling to make sure that it doesn't work.
Yes. It's exactly what Cisco wants.
I must say: I'm pissed. But I hope I could at least clarify this topic.
My next-best approach to circumvent this would be to define an intermediate privilege level that only has the permission to do the commands in question, and only assign the users in question to that lower priv-level. Scales poorly, but enough for us. Maybe that approach serves some others as well.
Or, use a tacacs+ to RADIUS gateway. Or, integrate Tacacs+ support into FreeRADIUS. If we had TCP as a transport layer, adding tacacs+ would be relatively easy. :) Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Guy Davies -
Stefan Winter