Has anyone had a chance to look into this? If the method is broken then I need to code a new way around this issue. I just need some assistance on which direction I should move forward with, developing the fix myself, or hope there is a simple solution.
Thanks! Dave Heinz From: David Heinz <[email protected]<mailto:[email protected]>> Date: Thu, 12 Jul 2012 17:35:49 -0400 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [RADIATOR] IOS-XR AuthorizeGroup TASK ID's We've recently realized we need the functionality of allowing IOS-XR devices to receive task groups (such as #root-system and #cisco-support) but still be able to utilize priv-lvl=15 on plain old IOS devices. I've following the instructions in the goodies file tacacsplusserver.cfg # In IOS XR the privilege levels have been removed in favor of more advanced # "task groups" which can also be provisioned via TACACS+ like this AuthorizeGroup xr-only permit service=shell cmd\* {task=#root-system,#cisco-support} # however, older Cisco boxes don't like the task attribute since it's not # implemented. To get around this you set the task attributes as optional # in the TACACS header. This is done by using an asterisk as a delimiter instead # as so: AuthorizeGroup xr-friendly permit service=shell cmd\* {task*#root-system,#cisco-support priv-lvl=15} # make sure you have priv-lvl=15 on the end cause XR maps up the old priv-lvls # to task groups and if it get's the priv-lvl before it get the task groups from # TACACS+ it's gonna map up 15 to #root-system instead of just reading the task # attribute. However, when my CRS receives the reply with the task* it only maps the priv-lvl=15 and my user has #root-system (which is priv-lvl=15). If I change the * to = then my task groups are mapped properly, but my IOS devices no longer authenticate and place the user into priv-lvl=15 access level. Have you seen this behavior before, and is this perhaps just an issue with my configuration (either in radiator or in tacacs on the routers themselves) AuthorizeGroup: permit service=shell cmd\* {task*#root-system,#cisco-support priv-lvl=15 idletime=45 timeout=600} permit service=raccess {priv-lvl=15 idletime=45 timeout=600} permit service=arbor {arbor_group=system_admin} deny service=shell cmd=test cmd-arg=crash deny service=shell cmd=debug cmd-arg=ip cmd-arg=packet deny service=shell cmd=debug cmd-arg=all permit .* Tacacs on IOS device: aaa new-model aaa authentication login default group tacacs+ local enable aaa authentication enable default group tacacs+ enable aaa authentication ppp default none aaa authorization console aaa authorization config-commands aaa authorization exec default group tacacs+ none aaa authorization commands 1 default group tacacs+ none aaa authorization commands 15 default group tacacs+ none aaa accounting exec default start-stop group tacacs+ aaa accounting commands 1 default start-stop group tacacs+ aaa accounting commands 15 default start-stop group tacacs+ aaa accounting network default start-stop group tacacs+ aaa accounting connection default start-stop group tacacs+ aaa accounting system default start-stop group tacacs+ IOS-XR Tacacs: aaa accounting exec default start-stop group tacacs+ none aaa accounting commands default start-stop group tacacs+ none aaa authorization exec default group tacacs+ local aaa authorization network default none aaa authorization commands default group tacacs+ none aaa authentication login default group tacacs+ local aaa authentication login no_tacacs local aaa authentication login console_method group tacacs+ local Also, I'm running Radiator 4.9 Dave Heinz
_______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
