ASR9000/XR Using Task groups and understanding Priv levels and authorization

[xthuijs]

Introduction

IOS-XR has a very strong embedded mechanism to do user authentication and authorization. While XR does not have the concept of privilege-levels as what IOS had, the embedded user task group management is extremely strong allow for the creation of different task groups.

Tasks

Building blocks for on-box authorization scheme
4 types of permissions per task

• Read
• Write
• Execute
• Debug

Tasks
aaa	config-services	hsrp	netflow	sbc
acl	crypto	interface	network	snmp
admin	diag	inventory	ospf	sonet-sdh
atm	disallowed	ip-services	ouni	static
basic-services	drivers	ipv4	pkg-mgmt	sysmgr
bcdl	eigrp	ipv6	pos-dpt	system
bfd	ext-access	isis	ppp	transport
bgp	fabric	logging	qos	tty-access
boot	fault-mgr	lpts	rib	tunnel
bundle	filesystem	monitor	rip	universal
cdp	firewall	mpls-ldp	root-lr	vlan
cef	fr	mpls-static	root-system	vrrp
cisco-support	hdlc	mpls-te	route-map
config-mgmt	host-services	multicast	route-policy

Default task-groups

The following task-groups are predefined in IOS-XR

root-system: Root system users

root-lr: Root logical router users

netadmin: Network administrators

sysadmin: System administrators

operator: Operators performing day-to-day activities

cisco-support: highest level of privilege allowing lowest level access

What task group is needed for what command?

If you are unsure as to what task group and permission level you need in order to allow a certain command, use the "describe" keyword.

Example:

RP/0/RSP0/CPU0:A9K-TOP#describe show bgp summary

.....
User needs ALL of the following taskids:

       bgp (READ)

So in order to allow a user to do the command "show bgp summary", we would need to allow the following line in

the task group definition:

task read bgp

It can also be the case that a particular user needs to be member of a particular (pre defined) task group.

such as a Process restart, you can only do when you are member of cisco-support:

RP/0/RSP0/CPU0:A9K-TOP# describe process restart bgp

.........

User needs ALL of the following taskids:

        cisco-support (EXECUTE)

Tasks and user group example

In regular IOS-XR configuration define your task-group with the permissions and tasks you like

RP/0/RSP0/CPU0:A9K-TOP(config)#taskgroup basic-admin
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task read acl
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task read bfd
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task read bgp
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task write acl
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task write bfd
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task write bgp
RP/0/RSP0/CPU0:A9K-TOP(config-tg)# task debug bgp

You can also define a user group that imports several task groups:

usergroup noc-staff
taskgroup operator
taskgroup basic-admin
inherit usergroup all-users

Privilege levels

As mentioned, XR doesn't have priv levels, but in order to leverage the existing AAA profiles from TACACS used for IOS based routes, we can create user-groups that are named as the privilege levels:

usergroup priv15

taskgroup root-system

taskgroup cisco-support

Now with tacacs we can send the priv via the options in service-exec:

service = exec {
priv-lvl = 15
}

or via a radius AVP like:

cisco-avpair = "shell:priv-lvl=15"

NOTE: the syntax of "cisco-avpair" and the capitalization is dependent on the dictionary definition for the cisco avp.

Using AAA

For starters you need to point your user authentication to the external source for authentication:

aaa authorization exec default group tacacs+ local
aaa authentication login default group tacacs+ local

when you add the following to your tacacs profile :

TACACS:

service = exec {
task = "rwx:bgp,#operator"
}

RADIUS:

Cisco-AVPair = "shell:tasks=#sysadmin,rwx:bgp,r:ospf"

you'll inherit the read, write and execute permissions to BGP as well as the user will be part of the local operator group definition.

Either this group is part of the standard cisco embedded groups or it can be something that you have defined locally.

the radius profile allows read/write/execute on BGP, read for OSPF and membership to the sysadmin group

By using AAA you can either reference locally defined task groups OR you can define the task groups in the tacacs/radius response packet

or using a combination of both

Group Membership

To find out which groups you are currently member of while being logged in:

RP/0/RSP0/CPU0:A9K-TOP#show user tasks
Wed Mar 30 18:26:00.768 UTC
Task:                  aaa  : READ    WRITE    EXECUTE    DEBUG
Task:                  acl  : READ    WRITE    EXECUTE    DEBUG
Task:                admin  : READ    WRITE    EXECUTE    DEBUG

Command Authorization

In IOS we can do command authorization for each separate priv level. in XR we don't have priv levels hence either command author is enabled for ALL commands or none at all:

RP/0/RSP0/CPU0:A9K-TOP(config)#aaa authorization commands default group ?
  WORD     server-group name
  tacacs+  Use list of all TACACS+ hosts

Note: in order to do command author you must use TACACS, you cannot use radius.

Related Information

n/a

Xander Thuijs - CCIE #6775

Sr Tech Lead ASR9000

[Andreas Martensson]

Great Info!

Does one have to user an external authentication source (tacacs) to do this?

I am trying to setup a local user with read-only rights to access the running-config.

/Andreas

[xthuijs]

Hi Andreas, thanks!

You can go either way about it:

You can define your task groups (that is task + permissions) in XR config and reference that group either in the

local configuration for the username, or when you use tacacs authentication, you can point with your tacacs reply attributes that this user should inherit the permissions from this locally defined task group.

Or instead of defining the task groups locally, you can also construct them in tacacs as per examples above.

A local ONLY configuration without any tacacs would come down to :

*define the task group with permissions*

RP/0/RSP0/CPU0:A9K-TOP(config)#taskgroup TEST

RP/0/RSP0/CPU0:A9K-TOP(config-tg)#task read <define all tasks that you want to see the running config of>

*define the usergroup, which is a set of task groups*

RP/0/RSP0/CPU0:A9K-TOP(config)#usergroup UGR taskgroup TEST

*define the local user that takes the user group*

RP/0/RSP0/CPU0:A9K-TOP(config-ug)#username andreas

RP/0/RSP0/CPU0:A9K-TOP(config-un)#group UGR

RP/0/RSP0/CPU0:A9K-TOP(config-un)#password test

cheers

xander

[manuv1984]

Hi Xander,

                    As you know , in ASR there are diffrent SDR's. We can partition the XR OS into different SDR's.I would like to know  how it will be ? Along with that there is a predefined user group called "root-lr". If we create a new user and add to "root-lr", how the router ditect the user belongs to which SDR ? and how the router differentiate the user from one SDR ro another ??  Iam expecting your valid response.

[xthuijs]

Whatever you put in the admin config is shared between all SDR's. Whatever is in the exec config is local to that particular router. If you use TACACS, then the SDR's present themselves as different devices hence different policies can apply.

If you do local authentication then the user database in admin config is shared between the SDR's.

Note by the way that ASR9000 does not support SDR's and this above is specific to CRS.

thanks

xander

[manuv1984]

Hi Xander,

                  Please clarify my doubt. In the configration guide of ASR, they have described ASR support SDR's. I have taken the below lines from config guide for your reference.

"The router operates in two planes: the administration (admin) plane and secure domain router (SDR) plane.

Each SDR has its own AAA configuration including, local users, groups, and TACACS+ and RADIUS

configurations. Users created in one SDR cannot access other SDRs unless those same users are configured

in the other SDRs." 

             If ASR doen't support SDR's , what they are specifying? Beacuse of that I got doubt how they will create a user for a particular SDR ?

[xthuijs]

SDR is secure domain router. In CRS you can divide a single physical chassis into separate routing entities that share the fabric, but have individual control planes.

ADMIN config applies to all SDR's within that single system.

In ASR9K, yeah sure you have an SDR, but it spans the entire chassis and you can't create multiple SDR's within the ASR9K, that is a CRS specific functionality.

So for ASR9K, your local users are defined in the admin config. Your task groups are defined in the exec config.

In the exec config are also the directives as to how to authenticate (local, radius, tacacs).

In TACACS you can define your permissions on a per user basis also.

TACACS is required for individual command authorization in case you do not want to use task based permissions.

RADIUS can be used for user authentication and task group assignment.

xander

[manuv1984]

Hi Xander,

                Yeah I got it what you are saying. But this sentece is quite confusing("Users created in one SDR cannot access other SDRs unless those same users are configured in the other SDRs."). If we can't create multiple SDR's within ASR 9k, why they are mentioning so ?

I know we can use " aaa accounting commands default start-stop group tacacs+" for acounting of each commands executed by the user. Instead of tacacs+ Can't we apply radius for the same purpose ?

[xthuijs]

Some documentation was "copied" from the CRS which in this case might have mislead you.

You should read this as is, but with the notion that 9k only has 1 SDR max, that's it, so in that regard the statement doesn't really apply to the 9k.

radius cant do command authorization because radius by nature doesn't have a separate author phase like tacacs employs.

So radius can be used for authentication (and assign the taskgroup/permissions to the user in the access-accept) and do session accounting. TACACS can do that also, but with the added capability of doing command author and accounting.

[manuv1984]

Hi Xander,

                 Ohh that's great information from you. Along with that they have specified the predefined usergroup in the router.

• root-lr: Has the ability to control and monitor the specific secure domain router.

• root-system: Has the ability to control and monitor the entire system.

           If there is only a single SDR, what is the difference between these two groups. Isn't "root-lr" available in ASR9k?

[xthuijs]

note that these "pre defined task groups" are say sort of the intend of use.

it depends on the specific command on what minimum permissions are required.

you can use the command "describe <the command of interest>" to see what the taskgroup the system would minimally require for this.

But to your point, theoretically if only one SDR these 2 groups are rather overlapping.

xander

[manuv1984]

Hi Xander,

                  Thanks for your quick response.  I am agreeing to your information. But in the configuration of SNMP community string also they are providing SDR owner and system owner.

                                                        Will both options provide the same result ?

[xthuijs]

documented quite nicely:

SDROwner (Optional) Limits access to the owner service domain router (SDR).

SystemOwner (Optional) Provides system-wide access including access to all non-owner SDRs.

SDRowner will give your commstr access to all snmp OID's that are specific to this SDR only

the Sysowner gives you access to OID's outside the scope of the SDR for instance power management and entity mib like variables such as temperatures.

I have that btw documented on a technote that you can find on the support forums (snmp access for voltage and temp management). You should be able to find it as a document under my profile.

xander

[Amjad Abdullah]

Hi Alex.

Useful doc indeed.

I could not figure out though where exactly to add the following lines in the TACACS+ server:

service = exec {
task = "rwx:bgp,#operator"
}

I expect those are added under the group (or user) config in the TACACS+ field. I can find only the field "Custom Attributes" can accept multi lines. When I add the lines though it complains that they do not seem to be correct.
Am I doing something wrong?

[xthuijs]

Thanks Amjad! Hmm as for the location of that section, this snippet is from the freeware tacacs server with the flat text config file.

If you have an ACS server or something then this should be put into the "exec" portion of the user or group profile.

Maybe this reference gives some of the procedures you need:

https://supportforums.cisco.com/thread/2098482

regards

xander

[Michael Gehrmann]

Ok that's great but how do I find out which command maps to which task? Is there a reference or a command I can check?

I am trying to find out what enables the command "show running-config".

Regards

Mike