[RADIATOR] IOS-XR AuthorizeGroup TASK ID's

[David Heinz]

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 <heinzdb at corp.earthlink.com<mailto:heinzdb at corp.earthlink.com>>
Date: Thu, 12 Jul 2012 17:35:49 -0400
To: "radiator at open.com.au<mailto:radiator at open.com.au>" <radiator at open.com.au<mailto:radiator at open.com.au>>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20120716/b49b466c/attachment-0001.html