-
Cisco IOS-XR System Security Configuration Guide, Release 2.0
-
Implementing Certification Authority Interoperability on Cisco IOS-XR Software
-
Implementing Internet Key Exchange Security Protocol on Cisco IOS-XR Software
-
Implementing IPSec Network Security on Cisco IOS-XR Software
-
Implementing Secure Shell on Cisco IOS-XR Software
-
Implementing Secure Socket Layer on Cisco IOS-XR Software
-
Configuring AAA Services on Cisco IOS-XR Software
-
Configuring Software Authentication Manager on Cisco IOS-XR Software
-
Table Of Contents
Configuring AAA Services on Cisco IOS-XR Software
Prerequisites for Implementing User Groups
Restrictions for Implementing User Groups
Information About Implementing User Groups
Comparison of Cisco IOS AAA and Cisco IOS-XR AAA Services
Cisco IOS-XR Software Administrative Model
Task IDs for TACACS Authenticated Users
How to Configure User Groups and Task Groups
Configuring Authentication Method Lists
Configuring Authorization Method Lists
Configuring Accounting Method Lists
Applying Method Lists for Applications
Configuration Examples for Configuring AAA Services
Configuring AAA Services: Example
Configuring AAA Services on Cisco IOS-XR Software
This chapter describes configuring the new administrative model of task-based authorization used to control user access in the Cisco IOS-XR system. The major tasks required to implement task-based authorization involve configuring user groups and task groups.
User groups and task groups are configured through the Cisco IOS-XR software command set used for authentication, authorization, and accounting (AAA) services. Authentication commands are used to verify the identity of a user or principal. Authorization commands are used to verify that an authenticated user (or principal) is granted permission to perform a specific task. Accounting commands are used to create an audit trail by recording certain user-generated or system-generated actions.
The AAA subsystem also provides the software commands used to establish system security.
This chapter describes the new and revised tasks you need to configure AAA services on your
Cisco IOS-XR network.
Note
For a complete description of the AAA commands listed in this module, refer to the Authentication, Authorization, and Accounting Commands on Cisco IOS-XR Software module in the Cisco IOS-XR System Security Command Reference publication. To locate documentation of other commands that appear in this chapter, use the command reference master index, or search online.
Feature History for Configuring AAA Services on Cisco IOS-XR Software
Contents
•
•
•
•
•
Prerequisites for Implementing User Groups
Configuring user groups and task groups is accomplished through the AAA feature. AAA is part of the base package and is available by default.
Establish a root-system user using the intial setup dialog. The administrator may configure a few local users without any specific AAA configuration. The external security server becomes necessary when the users of the router are configured within an administrative domain. A typical configuration would include the use of an external AAA security server and database with the local database option as a backup in case the external server becomes unreachable.
Restrictions for Implementing User Groups
Compatibility
Compatibility is verified with the Cisco freeware TACACS+ server only.
Interoperability
Router administrators can use the same AAA server software and database (for example, CiscoSecure) for the router and any other Cisco equipment that does not currently run Cisco IOS-XR software. To support interoperability between the router and external TACACS+ servers that do not support task IDs, the administrator must configure a local user for each user that has already been configured for the external TACACS+ server. The same username should be used for both local and external user configurations. Although the external TACACS+ server is used for authentication, the task IDs for the authenticated user are taken from the locally configured user (if the external server did not supply task IDs). This method of using task IDs from local users with the same name is just one of the available options for supporting task IDs in the case of external TACACS+ server authentication. For additional means of assigning task IDs for users authenticated with the Tacacs method, see the "Task IDs for TACACS Authenticated Users" section.
Information About Implementing User Groups
This section lists all the conceptual information that a new Cisco IOS-XR software user must understand before configuring user groups and task groups through AAA. Conceptual information also describes what AAA is and why it is important.
•
•
•
Comparison of Cisco IOS AAA and Cisco IOS-XR AAA Services
The differences between Cisco IOS AAA and Cisco IOS-XR AAA services are primarily based on the new administrative model of task-based authorization used to control user access in the Cisco IOS-XR system, replacing the Cisco IOS reliance on user privilege levels. The following points characterize the major differences between Cisco IOS software and Cisco IOS-XR software derived from task-based authorization:
•
•
Task IDs provide more flexibility and control than the privilege levels used in Cisco IOS software. For example, in Cisco IOS software both the configuration commands and reboot command are associated with level 15, which makes it difficult for administrators to assign those tasks to two different users. Although the privilege levels for commands can be redefined through configuration for specific command patterns, they will not be uniform across devices. Task-based authorization solves this administrative problem.
•
User and Group Attributes
Cisco IOS-XR software user attributes form the basis of the Cisco IOS-XR software administrative model. Each router user is associated with the following attributes:
•
•
•
User Categories
Router users are classified into the following categories:
•
•
•
Root-System Users
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 the logical routers in the system. At least one root-system user account must be created during router setup. There can be multiple root-system users.
The root-system user can perform any configuration or monitoring task, including the following:
•
•
•
•
Root-LR Users
A root-lr user controls the configuration and monitoring of a particular logical router (LR). The root-lr user can create users and configure their privileges within the LR. Multiple root-lr users can work independently on multiple LRs in the router system. A single LR may have more than one root-lr user.
A root-lr user can perform the following administrative tasks for a particular LR:
•
•
•
A root-lr user cannot deny access to a root-system user. (See the "Root-System Users" section.)
Logical Router Users
An LR user has restricted access to an LR as determined by the root-system user or root-lr user. The LR user performs the day-to-day system and network management activities. The tasks that the LR user is allowed to perform are determined by the task IDs associated with the user groups to which the LR user belongs. (See the "User Groups" section.)
User Groups
The Cisco IOS-XR software allows the system administrator to configure groups of users and the job characteristics that are common in groups of users. Groups must be explicitly assigned to users. Users are not assigned to groups by default. A user can be assigned to more than one group.
A user group defines a collection of users that share a set of attributes such as access privileges. Each user may be associated with one or more user groups. User groups have the following attributes:
•
•
Predefined User Groups
The Cisco IOS-XR software provides a collection of user groups whose attributes are already defined. The predefined groups are as follows:
•
•
•
•
•
•
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 LRs. Authorization is enabled by default for root-system users in any LR, including the root LR.
User-Defined User Groups
Administrators can configure their own user groups to meet particular needs.
User Group Inheritance
A user group can derive attributes from another user group. (Similarly, a task group can derive attributes from another task group. See the "Task Groups" section.) 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.
Cisco IOS-XR Software Administrative Model
The router operates in two planes: the administration (admin) plane and the logical router (LR) plane. The admin (shared) plane has the complete (administrative and nonadministrative) responsibilities for the root logical router and certain administrative responsibility for all other logical routers. The logical router plane has certain administrative responsibility and complete nonadministrative responsibility for nonroot LRs.
The root-system user has the highest level of responsibility for the router. It provisions logical routers and creates root-lr users. Once created, root-lr users take most of the responsibilities from the root-system user for the LR. Root-lr users in turn can create LR users. Root-system users and root-lr users have fixed permissions (task IDs) and cannot be changed by users.
Resource-Based Access
In the router system, certain resources are made available only for certain privileged types of users:
•
•
AAA Database
The AAA database stores the users, groups, and task information that controls access to the system. The AAA database can be either local or remote. The database that is used for a specific situation depends on the AAA configuration.
Local Database
AAA data such as users, user groups, and task groups can be stored locally within a logical router. The data is stored in the in-memory database and persists in the configuration file. The stored passwords must be encrypted. Note that this database is local to the specific LR in which it is stored, and the defined users or groups are not visible to other logical routers in the same Cisco CRS-1 Series router system.
Remote Database
AAA data can be stored in an external security server, such as Cisco Secure. 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, port, and key.
Remote AAA Configuration
Products such as Cisco Secure can be used to administer the shared or external AAA database. The router communicates with the remote AAA server using a standard IP-based security protocol (such as TACACS+). The security server should support enough logic to create the different classes of users appropriately.
Client Configuration
The security server should be configured with the secret key shared with the router and the IP addresses of the clients.
Root-System Users
Creating, modifying, or deleting root-system users should be done at the highest privilege of the security server. A user is a root-system user if that user is made a member of the root-system user group. If the user is configured as a member of the root-system user group, it does not make sense for the user to be a member of any other user group.
Root-LR Users
A user is a root-lr user if that user is made a member of the root-lr user group. A root-lr user cannot be made a member of any other group because the root-lr user permissions are predefined.
Logical Router Users
LR users can be created and made a member of multiple user groups. The effective task permission set is derived by making a union of all the permissions enabled by all the user groups.
User Groups
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 user groups is independent, and the router does not recognize the user group structure. The remote user groups only serve to give the external TACACS user attributes (such as service="exec-ext") that the router uses.
Configuration of user groups in external servers comes under the design of individual server products. Refer to the appropriate server product documentation.
Task Groups
Task groups are defined in terms of lists of permitted task IDs per type of actions (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 be configured in the Cisco TACACS+ server freeware.
AAA Configuration
This section provides information about AAA configuration.
Method Lists
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 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.
Rollover Mechanism
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 or authorization request is rejected by any database, the rollover does not occur and the request is rejected.
The following methods are available:
•
•
•
•
Server Grouping
Instead of maintaining a single global list of servers, the user can form server groups for different AAA protocols (such as RADIUS, TACACS+, and so on) and associate them with AAA applications (PPP, EXEC, and so on). In addition, certain common parameters for the group of servers (such as resend time) can be specified.
Authentication
Authentication is the most important security process by which a principal (a user or an application) obtains access to the system. The principal is identified by a username (or user ID) that is unique across an administrative domain. The applications serving the user (such as EXEC or Management Agent) procure the username and the credentials from the user. AAA performs the authentication based on the username and credentials passed to it by the applications.
Authentication in Router Resources
AAA follows a user group-based-authentication mechanism. The role of an authenticated user is determined by the group (or groups) to which the user belongs. (A user can be a member of one or more user groups.)
Authentication of Root-System User
The root-system user can log in to any node in any logical router in the system. When logging in from a nonroot logical router, the root-system user must add the "@admin" suffix to the username. Using the "@admin" suffix sends the authentication request to the root logical router for verification. The root logical 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.)
Authentication of Root-System User in Nonroot Logical Routers
Usernames must be qualified with the "@admin" suffix if root-system users are logging in through nonroot logical routers. This qualification causes authentication to be performed at the root logical router.
Authentication of Root-LR User
A root-lr user can log in only to all the nodes belonging to the specific LR associated with that root-lr user. If the user is member of root-lr group, then the user is authenticated as a root-lr user.
Authentication of LR User
LR user authentication is similar to root-lr user authentication. If the user is not found to be a member of the designated root-lr user group or root-system user group, the user is authenticated as an LR user.
Authentication Flow of Control
AAA performs authentication according to the following process:
1.
2.
3.
•
•
•
Clients can obtain a user's permitted task IDs during authentication. This information is obtained by forming a union of all the 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 and external API client can use this feature to optimize their operations. EXEC can avoid displaying the commands that are not applicable and an API client 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 will not be reflected in the user's current active session; they will take effect in the user's next session.
Ksh Authentication
The korn shell (ksh) is the primary shell for the aux port of the route processor (RP), standby RP, and distributed RP cards and for console and aux ports of line cards (LCs) and service processors (SPs). The following are some of the characteristics of ksh authentication:
•
•
•
•
•
•
•
Bypassing ksh Authentication
Although the authentication to ksh is lightweight and depends on very few processes, there are cases when ksh authentication needs to be bypassed, including the following:
•
•
•
To bypass ksh authentication, the user has to set the rommon variable AUX_AUTHEN_LEVEL to 0 and then reload the image. A reboot is required only on the card that has to bypass authentication.
The rommon variable AUX_AUTHEN_LEVEL can have one of the following values:
•
•
These backdoors allow access in abnormal situations such as the ones mentioned in the first three bullets.
•
Under no cirsumstances will authentication be bypassed. Even if authentication infrastructure is down, the system will simply deny access.
For example, to bypass authentication on the card, enter the following:
rommon1> AUX_AUTHEN_LEVEL=0rommon2> boot tftp:/ ...Password Types
In configuring a user and that user's group membership, you can specify two types of passwords: encrypted or clear text.
The router supports both two-way and one-way (secret) encrypted user passwords. Secret passwords are ideal for user login accounts because the original unencrypted password string cannot be deduced on the basis of the encrypted secret. Some applications (PPP, for example) require only two-way passwords because they must decrypt the stored password for their own function, such as sending the password in a packet. For a login user, both types of passwords may be configured, but a warning message is displayed if one type of password is configured while the other is already present.
If both secret and password are configured for a user, the secret takes precedence for all operations that do not require a decryptable password, such as login. For applications such as PPP, the two-way encrypted password is used even if a secret is present.
Task-Based Authorization
AAA employs "task permissions" for any control, configure, or monitor operation through CLI or API. The Cisco IOS software concept of privilege levels has been replaced in Cisco IOS-XR software by a task-based authorization system.
Task IDs
Router control, configure, or monitor operational tasks are represented by task IDs. A task ID defines the permission to execute an operation. Users are associated with sets of task IDs that define the breadth of their authorized access to the router.
Task IDs are assigned to users through the following means. Each user is associated with one or more user groups. Every user group is associated with one or more task groups; in turn, every task group is defined by a set of task IDs. Consequently, a user's association with a particular user group links that user to a particular set of task IDs. A user that is associated with a task ID can execute any operation associated with that task ID.
Every router control, configure, or monitor operation is defined by a particular set of task IDs. Task IDs are common for both CLI and API. A given CLI command or API invocation is associated with at least one or more task IDs. These associations are hard-coded within the router and may not be modified. Task IDs grant permission to perform certain tasks; task IDs do not deny permission to perform tasks. Task ID operations can be one, all, or a combination of the following:
•
•
•
•
The system verifies that each CLI command and API invocation conforms with the task ID permission list for the user. It compares the user's associated task IDs with the task IDs associated with the CLI or API invocation; if the compared task ID sets conform, then the user is allowed to execute the operation.
For more information about CLI commands and task ID operations, see the Cisco IOS-XR Task ID Reference Guide.
If you are experiencing problems using a CLI command, contact your system administrator.
Task Groups
A task group is defined by a collection of task IDs. Task groups contain task ID lists for each class of action.
Each user group is associated with a set of task groups applicable to the users in that group. A user's task permissions are derived from the task groups associated with the user groups to which that user belongs.
Predefined Task Groups
The following predefined task groups are available for administrators to use, typically for initial configuration:
•
•
•
•
•
•
User-Defined Task Groups
Users can configure their own task groups to meet particular needs.
Group Inheritance
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.
Task IDs for TACACS Authenticated Users
Cisco IOS-XR AAA provides the following means of assigning task permissions for users authenticated with the Tacacs method:
•
See the "Task Maps" section for more details.
•
See the "Privilege Level Mapping" section for more details.
•
•
For example, use the aaa default-tacacs-taskgroup tga command in global configuration mode to make tga the task group to be used to give user permissions after all Tacacs authentications.
Task Maps
For users who are authenticated using an external TACACS+ server, Cisco IOS-XR AAA supports a mapping between task IDs, user groups, and task groups defined for the user in the external TACACS+ server configuration file and local user groups and task groups.
Format of the Task String
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 below:
task = "<permissions>:<taskid name>, #<usergroup name>, ..."
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-groupopap = cleartext "lab"service = exec-ext {task = "rwx:bgp,#operator"}}The r,w,x (and n when appropriate) correspond to read, write, execute, and notify, respectively, and the pound sign (#) indicates that a user group follows.
After user1 successfully connects and logs in to the external TACACS+ server with user name user1 and appropriate password, the show user tasks command can be used in EXEC mode to display all of the tasks user1 can perform. For example:
Username:user1Password:RP/0/RP0/CPU0:router# show user tasksTask: bgp :READ WRITE EXECUTETask: basic-services :READ WRITE EXECUTE NOTIFYTask: cdp :READTask: diag :READTask: ext-access :READ EXECUTETask: logging :READAlternatively, if a user named user2, who does not have a task string, logs in to the external server, the following information is displayed:
Username:user2Password:RP/0/RP0/CPU0:router# show user tasksNo task ids availablePrivilege Level Mapping
For compatibility with TACACS+ daemons that do not support the concept of task IDs, AAA supports a mapping between privilege levels defined for the user in the external TACACS+ server configuration file and local user groups. Following TACACS+ authentication, the task map of the user group that has been mapped from the privilege level returned from the external TACACS+ server is assigned to the user. For example, if a privilege level of 5 is returned from the external TACACS server, AAA will attempt to get the task map of the local user group priv5. This mapping process is similar for other privilege levels from 1 to 13. For privilege level 15, the root-system user group is used; privilege level 14 maps to the user group root-lr.
For example, with the Cisco freeware tac+ daemon, the configuration file has to specify the priv_lvl in its configuration file, as shown in the following example:
user = sampleuser{member = barservice = exec-ext {priv_lvl = 5}}The number 5 in this example can be replaced with the priv_lvl that has to be assigned to the user sampleuser.
XML Schema for AAA Services
The eXtensible Markup Language (XML) interface uses requests and responses in XML document format to configure and monitor AAA. The AAA components publish the XML schema corresponding to the content and structure of the data used for configuration and monitoring. The XML tools and applications use the schema to communicate to the XML agent for performing the configuration.
The following AAA components publish their own XML schema:
•
•
•
How to Configure User Groups and Task Groups
To configure user groups and task groups, perform the tasks described in the following sections.
•
•
•
•
•
•
•
•
Configuring Task Groups
Task-based authorization employs the concept of a task ID as its basic element. A task ID defines the permission to execute an operation for a given user. Each user is associated with a set of permitted router operation tasks identified by task IDs. Users are granted authority by being assigned to user groups that are in turn associated with task groups. Each task group is associated with one or more task IDs selected from the Cisco CRS-1 Series router set of available task IDs. The first configuration task in setting up the Cisco CRS-1 Series router authorization scheme is to configure the task groups, followed by user groups, followed by individual users.
Task Group Configuration
Task groups are configured with a set of task IDs per action type.
The inherit taskgroup command may be used to derive permissions from another group. Cyclic references will be detected and rejected. It is not possible to inherit from the root-system and root-lr predefined groups.
Specific task IDs can be removed from a task group by specifying the no prefix for the task command.
The task group itself can be removed. Deleting a task group that is still referred to will result in an error.
Prerequisites
Before creating task groups and associating them with task IDs, the user should have some familiarity with the router list of task IDs and the purpose of each task ID. Use the show task supported command to display a complete list of task IDs.
Restrictions
Only root-system users with write permissions for the AAA task ID can configure task groups. Task groups cannot inherit properties from predefined groups such as root-system and root-lr.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
commitDETAILED STEPS
What to Do Next
After completing configuration of a full set of task groups, proceed to configure a full set of user groups as described in the "Configuring User Groups" section.
Configuring User Groups
User groups are configured with the command parameters for a set of users, such as task groups. Entering the usergroup command accesses the user group configuration submode. Users can remove specific user groups by using the no form of the usergroup command. Users can remove the user group itself by using the no form of the command without giving any parameters. Deleting a usergroup that is still referenced in the system will result in a warning.
Use the inherit usergroup command to copy permissions from other user groups. The user group will be inherited by the parent group and form a union of all task IDs specified in those groups. Cyclic inclusions are detected and rejected.
Restrictions
Only the root-system users or root-lr users or users associated with the WRITE:AAA task ID can configure user groups. User groups cannot inherit properties from predefined groups such as root-system and root-lr.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
commitDETAILED STEPS
What to Do Next
After completing configuration of a full set of user groups, proceed to configure individual users as described in the "Configuring Users" section.
Configuring Users
Perform this task to configure a user.
Each user is identified by a username that is unique across the administrative domain. Each user should be made a member of at least one user group. Deleting a user group may orphan the users associated with that group. The AAA server will authenticate orphaned users but most commands will not be authorized.
SUMMARY STEPS
1.
2.
3.
or
secret {0 | 5} password4.
5.
6.
or
commitDETAILED STEPS
What to Do Next
After completing configuration of a full set of users, configure TACACS+ servers (See the "Configuring a TACACS+ Server" section.)
Configuring a TACACS+ Server
This task configures a TACACS+ server.
The port, if not specified, defaults to the standard port number, 49. The timeout and key parameters can be specified globally for all the TACACS+ servers. The timeout specifies how long the AAA server will wait to receive a response from the TACACS+ server. The key specifies an authentication and encryption key shared between the AAA server and the TACACS+ server.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
or
commitDETAILED STEPS
What to Do Next
After configuring TACACS+ servers, configure AAA server groups. (See the "Configuring AAA Server Groups" section.)
Configuring AAA Server Groups
This task configures AAA server groups.
Only TACACS+ server groups can be configured because the TACACS+ protocol is the only one supported.
The user can enter one or more server commands. The server command specifies the host name or IP address of an external TACACS+ server. Once configured, this group can be referenced from the AAA method lists (used while configuring authentication, authorization, or accounting). (See the "Method Lists" section.)
Prerequisites
For configuration to succeed, the external server should be accessible at the time of configuration.
SUMMARY STEPS
1.
2.
3.
4.
5.
or
commitDETAILED STEPS
What to Do Next
Once configured, a server group can be referenced from the AAA method lists (used while configuring authentication, authorization, or accounting). After configuring server groups, define method lists by configuring authentication, authorization, and accounting.
Configuring AAA Method Lists
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 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.
This section contains the following procedures:
•
•
•
Configuring Authentication Method Lists
This task configures method lists for authentication.
Authentication Configuration
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
The authentication can be applied to tty lines through use of the login authentication line configuration submode command.
Creation of a Series of Authentication Methods
Use the aaa authentication command to create a series of authentication methods, or method list. A method list is a named list describing the authentication methods to be used (such as TACACS+), in sequence. The method will be one of the following:
•
•
•
If the method is TACACS+ servers, rather than server group, the TACACS+ server is chosen from the global pool of configured TACACS+ servers, in the order of configuration. Servers from this global pool are the servers that can be selectively added to a server group.
The subsequent methods of authentication are used only if the initial method returns an error, not if it fails.
Restrictions
The default method list is applied for all the interfaces for authentication, except when a different named method list is explicitly specified, in which case the explicitly specified method list overrides the default list.
For console port access, no authentication is performed if a default authentication routine is not set for a function. However, for all other points of access (vty, aux, and so on) the user will be expected to authenticate anyway (local authentication will be used if no method list is specified for the corresponding line and the default method list is also not defined).
Note
SUMMARY STEPS
1.
2.
3.
or
commit4.
DETAILED STEPS
What to Do Next
After configuring authentication method lists, configure authorization method lists. (See the "Configuring Authorization Method Lists" section).
Configuring Authorization Method Lists
This task configures method lists for authorization.
Authorization Configuration
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 Cisco IOS-XR software uses the first method listed to authorize users for specific network services; if that method fails to respond, the Cisco IOS-XR 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
Method lists are specific to the type of authorization being requested. The Cisco IOS-XR software supports three types of AAA authorization:
•
•
•
When you create a named method list, you are defining a particular list of authorization methods for the indicated authorization type. Once defined, method lists must be applied to specific lines or interfaces before any of the defined methods will be 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:
•
•
•
Creation of a Series of Authorization Methods
Use the aaa authorization command to set parameters for authorization and to create named method lists defining specific authorization methods that can be used on a per-line or per-interface basis.
The Cisco IOS-XR software supports the following methods for authorization:
•
•
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
What to Do Next
After configuring authorization method lists, configure accounting method lists. (See the "Configuring Accounting Method Lists" section.)
Configuring Accounting Method Lists
This task configures method lists for accounting.
Accounting Configuration
Currently, Cisco IOS-XR software supports only the Tacacs method for accounting. The router reports user activity to the TACACS+ 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 will be 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 TACACS+ sends a "start accounting" notice at the beginning of the requested process and a "stop accounting" notice at the end of the process. Accounting record is stored only on the TACACS+ server.
When AAA accounting is activated, the router monitors TACACS+ AV pairs pertinent to the connection. The router reports these attributes as accounting records, which are then stored in an accounting log on the security server.
Creation of a Series of Accounting Methods
Use the aaa accounting command to create default or named method lists defining specific accounting methods and that can be used on a per-line or per-interface basis.
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
What to Do Next
After configuring method lists, apply those method lists. (See the "Applying Method Lists for Applications" section.)
Applying Method Lists for Applications
After you configure method lists for authorization and accounting services, you can apply those method lists for applications that use those services (console, vty, aux, and so on). Applying method lists is accomplished by enabling AAA authorization and accounting.
This section contains the following procedures:
•
•
Enabling AAA Authorization
This task enables AAA authorization for a specific line or group of lines.
Method List Application
After you use the aaa authorization command to define a named authorization method list (or use the default method list) for a particular type of authorization, you must apply the defined lists to the appropriate lines in order for authorization to take place. Use the authorization command to apply the specified method lists (or, if none is specified, the default method list) to the selected line or group of lines.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
What to Do Next
After applying authorization method lists by enabling AAA authorization, apply accounting method lists by enabling AAA accounting. (See the "Enabling Accounting Services" section.)
Enabling Accounting Services
This task enables accounting services for a specific line of group of lines.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
What to Do Next
After applying accounting method lists by enabling AAA accounting services, configure login parameters. (See the "Configuring Login Parameters" section.)
Configuring Login Parameters
This task sets the interval that the server waits for reply to a login.
SUMMARY STEPS
1.
2.
3.
4.
or
commitDETAILED STEPS
Configuration Examples for Configuring AAA Services
This section provides the following configuration examples:
•
Configuring AAA Services: Example
The following examples show how to configure AAA services.
An authentication method list vty-authen is configured. This example specifies a method list that uses the list of all configured TACACS+ servers for authentication. If that method fails, the local username database method is used for authentication.
configureaaa authentication login vty-authen group tacacs+ localThe default method list for PPP is configured to use local method.
aaa authentication ppp default localA username user1 is created for login purposes, a secure login password is assigned, and user1 is made a root-system user. Configure similar settings for username user2.
username user1secret labgroup root-systemexitusername user2secret labexitA task group named tga is created, tasks are added to tga, a user group named uga is created, and uga is configured to inherit permissions from task group tga. A description is added to task group uga.
taskgroup tgatask read bgptask write ospfexitusergroup ugataskgroup tgadescription usergroup ugaexitUsername user2 is configured to inherit from user group uga.
username user2group ugaexitThree TACACS servers are configured.
tacacs-server host 1.1.1.1 port 1 key abctacacs-server host 2.2.2.2 port 2 key deftacacs-server host 3.3.3.3 port 3 key ghiA user group named priv5 is created, which will be used for users authenticated using the TACACS+ method and whose entry in the external TACACS+ daemon configuration file has a privilege level of 5.
usergroup priv5taskgroup operatorexitAn authorization method list vty-author is configured. This example specifies that command authorization be done using the list of all configured TACACS+ servers.
aaa authorization commands vty-author group tacacs+An accounting method list vty-acct is configured. This example specifies that start-stop command accounting be done using the list of all configured TACACS+ servers.
aaa accounting commands vty-acct start-stop group ta$For TACACS+ authentication, if, for example, a privilege level 8 is returned, and no local usergroup priv8 exists and no local user with the same name exists, the aaa default-tacacs-taskgroup tga command ensures that such users are given the taskmap of the task group tga.
aaa default-tacacs-taskgroup tgaFor line template vty, a line password is assigned that is used with line authentication and makes usergroup uga the group that is assigned for line authentication (if used), and makes vty-authen, vty-author, and vty-acct, respectively, the method lists that are used for authentication, authorization, and accounting.
line template vtypassword labusers group ugalogin authentication vty-authenauthorization commands vty-authoraccounting commands vty-acctexitA TACACS+ server group named abc is created and an already configured TACACS+ server is added to it.
aaa group server tacacs+ abcserver 3.3.3.3exitAdditional References
The following sections provide references related to configuring AAA services.
Related Documents
AAA services commands
Authentication, Authorization, and Accounting Commands on
Cisco IOS-XR Software
Technical Assistance
Copyright © 2004 Cisco Systems, Inc. All rights reserved.
