The root system user is the entity authorized to “own” the entire router chassis. The root system user functions with the highest privileges over all router components and can monitor all secure domain routers in the system. At least one root system user account must be created during router setup. Multiple root system users can exist.

The root system user can perform any configuration or monitoring task, including the following:

• Configure secure domain routers.

• Create, delete, and modify root SDR users (after logging in to the secure domain router as the root system user). (See the Root SDR Users section.)

• Create, delete, and modify secure domain router users and set user task permissions (after logging in to the secure domain router as the root system user). (See the Secure Domain Router (SDR) Users section.)

• Access fabric racks or any router resource not allocated to a secure domain router, allowing the root system user to authenticate to any router node regardless of the secure domain router configurations.

A root SDR user controls the configuration and monitoring of a particular SDR. The root SDR user can create users and configure their privileges within the SDR. Multiple root SDR users can work independently. A single SDR may have more than one root SDR user.

A root SDR user can perform the following administrative tasks for a particular SDR:

• Create, delete, and modify secure domain router users and their privileges for the SDR. (See the Secure Domain Router (SDR) Users section.)

• Create, delete, and modify user groups to allow access to the SDR.

• Manage nearly all aspects of the SDR.

A root SDR user cannot deny access to a root system user. (See the Root System Users section.)

A SDR user has restricted access to an SDR as determined by the root-system user or root SDR user. The SDR user performs the day-to-day system and network management activities. The tasks that the secure domain router user is allowed to perform are determined by the task IDs associated with the user groups to which the SDR user belongs. (See the User Groups section.)

The Cisco IOS XR software provides a collection of user groups whose attributes are already defined. The predefined groups are as follows:

• cisco-support: This group is used by the Cisco support team.

• netadmin: Has the ability to control and monitor all system and network parameters.

• operator: A demonstration group with basic privileges.

• 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.

• sysadmin: Has the ability to control and monitor all system parameters but cannot configure network protocols.

• serviceadmin: Service administration tasks, for example, Session Border Controller (SBC).

The user group root-system has root system users as the only members. (See the Root System Users section.) The root-system user group has predefined authorization; that is, it has the complete responsibility for root-system user-managed resources and certain responsibilities in other SDRs.

Administrators can configure their own user groups to meet particular needs.

A user group can derive attributes from another user group. (Similarly, a task group can derive attributes from another task group). For example, when user group A inherits attributes from user group B, the new set of task attributes of the user group A is a union of A and B. The inheritance relationship among user groups is dynamic in the sense that if group A inherits attributes from group B, a change in group B affects group A, even if the group is not reinherited explicitly.

The following predefined task groups are available for administrators to use, typically for initial configuration:

• cisco-support: Cisco support personnel tasks

• netadmin: Network administrator tasks

• operator: Operator day-to-day tasks (for demonstration purposes)

• root-lr: Secure domain router administrator tasks

• root-system: System-wide administrator tasks

• sysadmin: System administrator tasks

• serviceadmin: Service administration tasks, for example, SBC

Users can configure their own task groups to meet particular needs.

Task groups support inheritance from other task groups. (Similarly, a user group can derive attributes from another user group. See the User Groups section.) For example, when task group A inherits task group B, the new set of attributes of task group A is the union of A and B.

AAA data, such as users, user groups, and task groups, can be stored locally within a secure domain router. The data is stored in the in-memory database and persists in the configuration file. The stored passwords are encrypted.

Note	The database is local to the specific secure domain router (SDR) in which it is stored, and the defined users or groups are not visible to other SDRs in the same system.

You can delete the last remaining user from the local database. If all users are deleted when the next user logs in, the setup dialog appears and prompts you for a new username and password.

Note	The setup dialog appears only when the user logs into the console.

AAA data can be stored in an external security server, such as CiscoSecure ACS. Security data stored in the server can be used by any client (such as a network access server [NAS]) provided that the client knows the server IP address and shared secret.

The security server should be configured with the secret key shared with the router and the IP addresses of the clients.

User groups that are created in an external server are not related to the user group concept that is used in the context of local AAA database configuration on the router. The management of external TACACS+ server or RADIUS server user groups is independent, and the router does not recognize the user group structure. The remote user or group profiles may contain attributes that specify the groups (defined on the router) to which a user or users belong, as well as individual task IDs. For more information, see the Task IDs for TACACS+ and RADIUS Authenticated Users section.

Configuration of user groups in external servers comes under the design of individual server products. See the appropriate server product documentation.

Task groups are defined by lists of permitted task IDs for each type of action (such as read, write, and so on). The task IDs are basically defined in the router system. Task ID definitions may have to be supported before task groups in external software can be configured.

Task IDs can also be configured in external TACACS+ or RADIUS servers.

AAA data may be stored in a variety of data sources. AAA configuration uses method lists to define an order of preference for the source of AAA data. AAA may define more than one method list and applications (such as login) can choose one of them. For example, console and auxiliary ports may use one method list and the vty ports may use another. If a method list is not specified, the application tries to use a default method list. If a default method list does not exist, AAA uses the local database as the source.

AAA can be configured to use a prioritized list of database options. If the system is unable to use a database, it automatically rolls over to the next database on the list. If the authentication, authorization, or accounting request is rejected by any database, the rollover does not occur and the request is rejected.

The following methods are available:

• Local: Use the locally configured database (not applicable for accounting and certain types of authorization)

• TACACS+: Use a TACACS+ server (such as CiscoSecure ACS)

• RADIUS: Use a RADIUS server

• Line: Use a line password and user group (applicable only for authentication)

• None: Allow the request (not applicable for authentication)

Instead of maintaining a single global list of servers, the user can form server groups for different AAA protocols (such as RADIUS and TACACS+) and associate them with AAA applications (such as PPP and EXEC mode).

The root-system user can log in to any node in any secure domain router in the system. A user is a root-system user if he or she belongs to the root-system group. The root-system user may be defined in the local or remote AAA database.

When logging in from a non-owner secure domain router, the root system user must add the “@admin” suffix to the username. Using the “@admin” suffix sends the authentication request to the owner secure domain router for verification. The owner secure domain router uses the methods in the list-name remote for choosing the authentication method. The remote method list is configured using the aaa authentication login remote method1 method2... command. (See the Configuring AAA Method Lists section.)

An owner secure domain router user can log in only to the nodes belonging to the specific secure domain router associated with that owner secure domain router user. If the user is member of a root-sdr group, the user is authenticated as an owner secure domain router user.

Secure domain router user authentication is similar to owner secure domain router user authentication. If the user is not found to be a member of the designated owner secure domain router user group or root-system user group, the user is authenticated as a secure domain router user.

AAA performs authentication according to the following process:

1. A user requests authentication by providing a username and password (or secret).

2. AAA verifies the user’s password and rejects the user if the password does not match what is in the database.

3. AAA determines the role of the user (root system user, root SDR user, or SDR user).

• If the user has been configured as a member of a root-system user group, then AAA authenticates the user as a root-system user.

• If the user has been configured as a member of an owner secure domain router user group, then AAA authenticates the user as an owner secure domain router user.

• If the user has not been configured as a member of a root-system user group or an owner secure domain router user group, AAA authenticates the user as a secure domain router user.

Clients can obtain a user’s permitted task IDs during authentication. This information is obtained by forming a union of all task group definitions specified in the user groups to which the user belongs. Clients using such information typically create a session for the user (such as an API session) in which the task ID set remains static. Both the EXEC mode and external API clients can use this feature to optimize their operations. EXEC mode can avoid displaying the commands that are not applicable and an EMS application can, for example, disable graphical user interface (GUI) menus that are not applicable.

If the attributes of a user, such as user group membership and, consequently, task permissions, are modified, those modified attributes are not reflected in the user’s current active session; they take effect in the user’s next session.

The korn shell (ksh) is the primary shell for the auxiliary port of the route processor (RP), standby RP, and distributed RP cards and for console and auxiliary ports of line cards (LCs) and service processors (SPs). The following are some of the characteristics of ksh authentication:

• For security reasons, ksh authentication allows only root-system users who have a secret configured. A root-system user with a normal password will not be authenticated because the normal password is two-way encrypted and poses a security risk because the password information is stored in the flash disk, which can be easily decrypted.

• Every time a root-system user with a secret is configured using the normal AAA CLI, that user is a valid ksh user and no separate configuration is required.

• Ksh does not authenticate TACACS+ or RADIUS users, even if they are root-system users.

• Ksh authentication uses a single user password database, which means when a root-system user on a dSC is configured using the normal AAA CLI, that user can log in using this username password in any card. This includes the RP, standby RP, LC, and SP.

• Ksh authentication cannot be turned off or bypassed after the card is booted. To bypass authentication, a user needs a reload of the card. (See the “Bypassing ksh Authentication” section for details).

• The ksh run from the console (using the run command) is not authenticated because the run command needs the root-system task ID. Because the user is already root-system, the user is not authenticated again.

rommon1> AUX_AUTHEN_LEVEL=0
rommon2> sync
rommon2> boot tftp:/ ... 

aaa authentication login default group tacacs+ group radius local
line template aux
login authentication default

This is because following the reload, the auxiliary port rejects login attempts with a valid TACACS+ configured username and password.

In such a scenario, the user has to first login with a valid locally configured username and password, and any login thereafter with TACACS+ configured username and password. Alternatively, if the user is connected to the auxiliary port via a terminal server, first clear the line used on the terminal server itself, and thereafter the user will be able to login to the auxiliary port with the TACACS+ configured username and password.

The task string in the configuration file of the TACACS+ server consists of tokens delimited by a comma (,). Each token contains either a task ID name and its permissions or the user group to include for this particular user, as shown in the following example:

task = “ permissions : taskid name , # usergroup name , ...”

Note

Cisco IOS XR software allows you to specify task IDs as an attribute in the external RADIUS or TACACS+ server. If the server is also shared by non-Cisco IOS XR software systems, these attributes are marked as optional as indicated by the server documentation. For example, CiscoSecure ACS and the freeware TACACS+ server from Cisco require an asterisk (*) instead of an equal sign (=) before the attribute value for optional attributes. If you want to configure attributes as optional, refer to the TACACS+ server documentation.

For example, to give a user named user1 BGP read, write, and execute permissions and include user1 in a user group named operator, the username entry in the external server’s TACACS+ configuration file would look similar to the following:

user = user1{
member = some-tac-server-group
opap = cleartext "lab"
service = exec {
task = "rwx:bgp,#operator"
}
}

The r,w,x, and d correspond to read, write, execute and debug, respectively, and the pound sign (#) indicates that a user group follows.

Note	The optional keyword must be added in front of “task” to enable interoperability with systems based on Cisco IOS software.

If CiscoSecure ACS is used, perform the following procedure to specify the task ID and user groups:

1.    Enter your username and password.

2.    Click the Group Setup button to display the Group Setup window.

3.    From the Group drop-down list, select the group that you want to update.

4.    Click the Edit Settings button.

5.    Use the scroll arrow to locate the Shell (exec) check box.

6.    Check the Shell (exec) check box to enable the custom attributes configuration.

7.    Check the Custom attributes check box.

8.    Enter the following task string without any blank spaces or quotation marks in the field:

9.    Click the Submit + Restart button to restart the server.

task=rwx:bgp,#netadmin

user Auth-Type := Local, User-Password == lab
        Service-Type = NAS-Prompt-User,
        Reply-Message = "Hello, %u",
        Login-Service = Telnet,
        Cisco-AVPair = "shell:tasks=#sysadmin,rwx:bgp,r:ospf"

Username:user1
Password:
RP/0/RP0/CPU0:router# show user tasks

Task:      basic-services  :READ    WRITE    EXECUTEDEBUG
Task:                 bgp  :READ    WRITE    EXECUTE
Task:                 cdp  :READ
Task:                diag  :READ
Task:          ext-access  :READ             EXECUTE
Task:             logging  :READ

Username:user2
Password:
RP/0/RP0/CPU0:router# show user tasks
No task ids available

Authentication is the process by which a user (or a principal) is verified. Authentication configuration uses method lists to define an order of preference for the source of AAA data, which may be stored in a variety of data sources. You can configure authentication to define more than one method list and applications (such as login) can choose one of them. For example, console and aux ports may use one method list and the vty ports may use another. If a method list is not specified, the application tries to use a default method list.

Note	Applications should explicitly refer to defined method lists for the method lists to be effective.

The authentication can be applied to tty lines through use of the login authentication line configuration submode command.

Before You Begin

Note

The default method list is applied for all the interfaces for authentication, except when a non-default named method list is explicitly configured, in which case the named method list is applied. The group radius, group tacacs+, and group group-name forms of the aaa authentication command refer to a set of previously defined RADIUS or TACACS+ servers. Use the radius server-host or tacacs-server host command to configure the host servers. Use the aaa group server radius or aaa group server tacacs+ command to create a named group of servers.

1.    configure


2.    aaa authentication {login | ppp} {default | list-name | remote} method-list


3.    commit


4.    Repeat Step 1 through Step 3 for every authentication method list to be configured.

RP/0/RP0/CPU0:router(config)# aaa authentication login default group tacacs+

After configuring authentication method lists, configure authorization method lists. (See the Configuring Authorization Method Lists section).

Method lists for authorization define the ways authorization will be performed and the sequence in which these methods will be performed. A method list is a named list describing the authorization methods to be used (such as TACACS+), in sequence. Method lists enable you to designate one or more security protocols to be used for authorization, thus ensuring a backup system if the initial method fails. The software uses the first method listed to authorize users for specific network services; if that method fails to respond, the software selects the next method listed in the method list. This process continues until there is successful communication with a listed authorization method, or until all methods defined have been exhausted.

Note

The software attempts authorization with the next listed method only when there is no response or an error response (not a failure) from the previous method. If authorization fails at any point in this cycle—meaning that the security server or local username database responds by denying the user services—the authorization process stops and no other authorization methods are attempted.

Method lists are specific to the type of authorization being requested. Four types of AAA authorization are supported:

• Commands authorization—Applies to the EXEC mode mode commands a user issues. Command authorization attempts authorization for all EXEC mode mode commands.

  Note	“Command” authorization is distinct from “task-based” authorization, which is based on the task profile established during authentication.

• EXEC mode authorization—Applies authorization for starting EXEC mode session.

• Network authorization—Applies authorization for network services, such as IKE.

• Eventmanager authorization—Applies an authorization method for authorizing an event manager (fault manager). RADIUS servers are not allowed to be configured for the event manager (fault manager) authorization. You are allowed to use TACACS+ or locald.

When you create a named method list, you are defining a particular list of authorization methods for the indicated authorization type. When defined, method lists must be applied to specific lines or interfaces before any of the defined methods are performed. Do not use the names of methods, such as TACACS+, when creating a new method list.

“Command” authorization, as a result of adding a command authorization method list to a line template, is separate from, and is in addition to, “task-based” authorization, which is performed automatically on the router. The default behavior for command authorization is none. Even if a default method list is configured, that method list has to be added to a line template for it to be used.

The aaa authorization commands command causes a request packet containing a series of attribute value (AV) pairs to be sent to the TACACS+ daemon as part of the authorization process. The daemon can do one of the following:

• Accept the request as is.

• Refuse authorization.

1.    configure


2.    aaa authorization {commands | eventmanager | exec | network} {default | list-name} {none | local | group {tacacs+ | radius | group-name}}


3.    commit

RP/0/RP0/CPU0:router(config)# aaa authorization commands listname1 group tacacs+

After configuring authorization method lists, configure accounting method lists. (See the Configuring Accounting Method Lists section.)

Currently, Cisco IOS XR software supports both the TACACS+ and RADIUS methods for accounting. The router reports user activity to the TACACS+ or RADIUS security server in the form of accounting records. Each accounting record contains accounting AV pairs and is stored on the security server.

Method lists for accounting define the way accounting is performed, enabling you to designate a particular security protocol to be used on specific lines or interfaces for particular types of accounting services. When naming a method list, do not use the names of methods, such as TACACS+.

For minimal accounting, include the stop-only keyword to send a “stop accounting” notice at the end of the requested user process. For more accounting, you can include the start-stop keyword, so that the external AAA server sends a “start accounting” notice at the beginning of the requested process and a “stop accounting” notice at the end of the process. In addition, you can use the aaa accounting update command to periodically send update records with accumulated information. Accounting records are stored only on the TACACS+ or RADIUS server.

When AAA accounting is activated, the router reports these attributes as accounting records, which are then stored in an accounting log on the security server.

1.    configure


2.    Do one of the following:

• aaa accounting {commands | exec | network} {default | list-name} {start-stop | stop-only}
• {none | method}

3.    commit

RP/0/RP0/CPU0:router(config)# aaa accounting commands default stop-only group tacacs+

After configuring method lists, apply those method lists. (See the Applying Method Lists for Applications section.)

1.    configure


2.    line {aux | console | default | template template-name}


3.    authorization {commands | exec} {default | list-name}


4.    commit

RP/0/RP0/CPU0:router(config)# line console

RP/0/RP0/CPU0:router(config-line)# authorization commands listname5

After applying authorization method lists by enabling AAA authorization, apply accounting method lists by enabling AAA accounting. (See the Enabling Accounting Services section.)