-
sc38book.html
-
Configuring AAA Services on Cisco IOS XR Software
-
Implementing Certification Authority Implementation on Cisco IOS XR Software
-
Implementing Internet Key Exchange Security Protocol on Cisco IOS XR Software
-
Implementing Keychain Management on Cisco IOS XR Software
-
Implementing Secure Shell on Cisco IOS XR Software
-
Implementing Secure Socket Layer on Cisco IOS XR Software
-
Index
-
Table Of Contents
Configuring AAA Services on Cisco IOS XR Software
Prerequisites for Configuring AAA Services
Restrictions for Configuring AAA Services
Information About Configuring AAA Services
User, User Groups, and Task Groups
Cisco IOS XR Software Administrative Model
General Usage Guidelines for Task IDs
Task IDs for TACACS+ and RADIUS Authenticated Users
Network Security Situations in Which RADIUS Is Unsuitable
Configuring Router to RADIUS Server Communication
Configuring RADIUS Dead-Server Detection
Configuring RADIUS Server Groups
Configuring TACACS+ Server Groups
Configuring Authentication Method Lists
Configuring Authorization Method Lists
Configuring Accounting Method Lists
Generating Interim Accounting Records
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 and authorization 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 for logging of sessions and to create an audit trail by recording certain user- or system-generated actions.
AAA is part of the base package and is available by default.
This module describes the tasks that 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, see 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
Release 2.0
This feature was introduced on the Cisco CRS-1.
Release 3.0
No modification.
Release 3.2
Support was added for the Cisco XR 12000 Series Router.
Release 3.3.0
•
•
•
•
•
•
•
•
•
Release 3.4.0
•
•
•
Release 3.5.0
No modification.
Release 3.6.0
The eventmanager keyword (fault manager) replaces the exec keyword to authorize event managers (fault managers) from the aaa authorization command.
Release 3.7.0
No modification.
Release 3.8.0
Information was edited to make clearer which features are supported on the Cisco CRS-1 and which on the Cisco XR 12000 Series Router exclusively.
Contents
•
•
•
•
•
Prerequisites for Configuring AAA Services
The following are prerequisites to configuring AAA services:
•
If you need assistance with your task group assignment, contact your system administrator. For detailed information about user groups and task IDs, consult this module.
•
Restrictions for Configuring AAA Services
This section lists the restrictions for configuring AAA services.
Compatibility
Compatibility is verified with the Cisco freeware TACACS+ server and FreeRADIUS only.
Interoperability
Router administrators can use the same AAA server software and database (for example,
CiscoSecure ACS) 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, see the "Task IDs for TACACS+ and RADIUS Authenticated Users" section.Information About Configuring AAA Services
This section lists all the conceptual information that a Cisco IOS XR software user must understand before configuring user groups and task groups through AAA or configuring Remote Authentication Dial-in User Service (RADIUS) or TACACS+ servers. Conceptual information also describes what AAA is and why it is important.
•
•
•
User, User Groups, and Task Groups
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 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:
•
•
•
•
Root SDR Users
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:
•
•
•
A root SDR user cannot deny access to a root system user. (See the "Root System Users" section.)
Secure Domain Router Users
A secure domain router user has restricted access to an SDR as determined by the root-system user or root SDR user. The secure domain router 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 secure domain router user belongs. (See the "User Groups" section.)
User Groups
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 SDRs.
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). 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, and change in group B affects group A, even if the group is not re-inherited explicitly.
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.
Cisco IOS XR Software Administrative Model
The router operates in two planes: the administration (admin) plane and secure domain router (SDR) plane. The admin (shared) plane consists of resources shared across all SDRs, while the SDR plane consists of those resources specific to the particular SDR.
The root-system user has the highest level of responsibility for the router. This user provisions secure domain routers and creates root SDR users. After being created, root SDR users take most of the responsibilities from the root-system user for the SDR. Root SDR users in turn can create secure domain router users. Root-system users and root SDR users have fixed permissions (task IDs) that cannot be changed by users.
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.
Administrative Access
Administrative access to the system can be lost if the following operations are not well understood and carefully planned. A lockout of all root-system users is a serious issue that requires a system reload to recover the password.
•
The none option for authentication is not supported in Cisco IOS XR software. Cisco IOS XR user access is more secure than Cisco IOS software, and there is no way that a user can access the system without a valid username and password.
•
•
To avoid a lockout, we recommend one or both of the following:
•
•
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 secure domain router. The data is stored in the in-memory database and persists in the configuration file. The stored passwords are encrypted.
Note
Unlike releases earlier than Release 3.3.0, you are able to delete the last remaining user from the local database. If all users are deleted and when the next user logs in, the setup dialog appears and prompts you for a new username and password.
Note
Remote Database
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.
Remote AAA Configuration
Products such as CiscoSecure ACS 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+ or RADIUS).
Client Configuration
The security server should be configured with the secret key shared with the router and the IP addresses of the clients.
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 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
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 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 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.
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, authorization, or accounting 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 and TACACS+) and associate them with AAA applications (such as PPP and EXEC).
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. 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 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.
Authentication of Non-Owner Secure Domain Router User
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.)
Authentication of Owner Secure Domain Router User
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.
Authentication of 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.
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 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 clients can use this feature to optimize their operations. EXEC 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.
Korn Shell Authentication
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:
•
•
•
•
•
•
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:
•
•
•
Under no circumstances is authentication bypassed. Even if the authentication infrastructure is down, the system simply denies access.
For example, to bypass authentication on the card, enter the following:
rommon1> AUX_AUTHEN_LEVEL=0rommon2> syncrommon2> 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 password that can be decrypted, such as a 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
The operational tasks that enable users to control, configure, and monitor Cisco IOS XR software are represented by task IDs. A task ID defines the permission to run an operation for a command. 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.
General Usage Guidelines for Task IDs
Every router control, configuration, or monitoring operation (CLI or XML API) is associated with a particular set of task IDs. 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 classes that are listed in Table 2.
The system verifies that each CLI command and API invocation conforms with the task ID permission list for the user. If you are experiencing problems using a CLI command, contact your system administrator.
Multiple task ID operations separated by a slash (for example, read/write) mean that both operations are applied to the specified task ID.
Multiple task ID operations separated by a comma (for example, read, read/write) mean that both operations are applied to the respective task IDs. For example, the copy ipv4 access-list command can have the read and write operations applied to the acl task ID, and the execute operation applied to the filesystem task ID.
If the task ID and operations columns have none specified, the command is used without previous user association to a task ID and operation. In addition, users do not need to be associated to task IDs to use ROM monitor commands.
Users may need to be associated to additional task IDs to use a command if the command is used in a specific configuration submode. For example, to execute the show redundancy command, a user needs to be associated to the system (read) task ID and operations as shown in the following example:
RP/0/RP0/CPU0:router# show redundancyWhereas, in administration EXEC mode, a user needs to be associated to both admin and system (read) task IDs and operations, as shown in the following example:
RP/0/RP0/CPU0:router# adminRP/0/RP0/CPU0:router(admin)# show redundancyTask IDs for TACACS+ and RADIUS Authenticated Users
Cisco IOS XR AAA provides the following means of assigning task permissions for users authenticated with the TACACS+ and RADIUS methods:
•
See the "Task Maps" section for more details.
•
See the "Privilege Level Mapping" section for more details.
•
•
Task Maps
For users who are authenticated using an external TACACS+ server and RADIUS server, Cisco IOS XR AAA supports a method to define task IDs remotely.
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 in the following example:
task = "permissions:taskid name, #usergroup name, ..."
Note
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 {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
If CiscoSecure ACS is used, perform the following procedure to specify the task ID and user groups:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
task=rwx:bgp,#netadminStep 8
The following RADIUS Vendor-Specific Attribute (VSA) example shows that the user is part of the sysadmin predefined task group, can configure BGP, and can view the configuration for OSPF:
user Auth-Type := Local, User-Password == labService-Type = NAS-Prompt-User,Reply-Message = "Hello, %u",Login-Service = Telnet,Cisco-AVPair = "shell:tasks=#sysadmin,rwx:bgp,r:ospf"After user1 successfully connects and logs in to the external TACACS+ server with username user1 and appropriate password, the show user tasks command can be used in EXEC mode to display all the tasks user1 can perform. For example:
Username:user1Password:RP/0/RP0/CPU0:router# show user tasksTask: basic-services :READ WRITE EXECUTE DEBUGTask: bgp :READ WRITE EXECUTETask: 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 attempts 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 owner-sdr.
For example, with the Cisco freeware tac plus server, the configuration file has to specify priv_lvl in its configuration file, as shown in the following example:
user = sampleuser1{member = barservice = exec-ext {priv_lvl = 5}}The number 5 in this example can be replaced with any privilege level that has to be assigned to the user sampleuser.
With the RADIUS server, task IDs are defined using the Cisco-AVPair, as shown in the following example:
user = sampleuser2{member = barCisco-AVPair = "shell:tasks=#root-system,#cisco-support"{Cisco-AVPair = "shell:priv-lvl=10"}}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 schema are published by AAA:
•
•
•
•
About RADIUS
RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication and accounting requests to a central RADIUS server that contains all user authentication and network service access information.
RADIUS is a fully open protocol, distributed in source code format, that can be modified to work with any security system currently available on the market.
Cisco supports RADIUS under its AAA security paradigm. RADIUS can be used with other AAA security protocols, such as TACACS+, Kerberos, and local username lookup.
Note
RADIUS has been implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.
Use RADIUS in the following network environments that require access security:
•
•
•
•
•
•
Network Security Situations in Which RADIUS Is Unsuitable
RADIUS is not suitable in the following network security situations:
•
–
–
–
–
•
•
RADIUS Operation
When a user attempts to log in and authenticate to an access server using RADIUS, the following steps occur:
1.
2.
3.
a.
b.
c.
d.
The ACCEPT or REJECT response is bundled with additional data that is used for EXEC or network authorization. You must first complete RADIUS authentication before using RADIUS authorization. The additional data included with the ACCEPT or REJECT packets consists of the following:
•
•
How to Configure AAA Services
To configure AAA services, 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 set of available task IDs. The first configuration task in setting up the Cisco CRS-1 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. Circular references are detected and rejected. It is not possible to inherit from the root-system and owner-sdr 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 elsewhere results in an error.
Prerequisites
Before creating task groups and associating them with task IDs, you should have some familiarity with the router list of task IDs and the purpose of each. To display a complete list of task IDs, use the show task supported command.
Restrictions
Only users with write permissions for the AAA task ID can configure task groups.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
commitDETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
taskgroup taskgroup-name
Example:RP/0/RP0/CPU0:router(config)# taskgroup beta
Creates a name for a particular task group and enters task group configuration submode.
•
Step 3
description string
Example:RP/0/RP0/CPU0:router(config-tg)# description this is a sample task group description
(Optional) Creates a description of the task group named in Step 2.
Step 4
inherit taskgroup taskgroup-name
Example:RP/0/RP0/CPU0:router(config-tg)# inherit taskgroup sysadmin
(Optional) Derives permissions from another task group and assigns them to the task group named in Step 2.
•
•
Step 5
task {read | write | execute | debug} taskid-name
Example:RP/0/RP0/CPU0:router(config-tg)# task read bgp
Specifies a task ID to be associated with the task group named in Step 2.
•
•
Step 6
Repeat Step 5 for each task ID to be associated with the task group named in Step 2.
—
Step 7
end
or
commit
Example:RP/0/RP0/CPU0:router(config-tg)# end
or
RP/0/RP0/CPU0:router(config-tg)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
What to Do Next
After completing configuration of a full set of task groups, 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. Deleting a usergroup that is still referenced in the system results in a warning.
Use the inherit usergroup command to inherit permissions from other user groups. The user group is inherited by the parent group and forms a union of all task IDs specified in those groups. Circular inclusions are detected and rejected.
Restrictions
Only 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 owner-sdr.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
or
commitDETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
usergroup usergroup-name
Example:RP/0/RP0/CPU0:router(config)# usergroup beta
Creates a name for a particular user group and enters user group configuration submode.
•
Step 3
description string
Example:RP/0/RP0/CPU0:router(config-ug)# description this is a sample user group description
(Optional) Creates a description of the user group named in Step 2.
Step 4
inherit usergroup usergroup-name
Example:RP/0/RP0/CPU0:router(config-ug)# inherit usergroup sales
Derives permissions from another user group and assigns them to the user group named in Step 2.
•
•
Step 5
taskgroup taskgroup-name
Example:RP/0/RP0/CPU0:router(config-ug)# taskgroup beta
Associates the user group named in Step 2 with the task group named in this step.
•
Step 6
Repeat Step 5 for each task group to be associated with the user group named in Step 2.
—
Step 7
end
or
commit
Example:RP/0/RP0/CPU0:router(config-ug)# end
or
RP/0/RP0/CPU0:router(config-ug)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
What to Do Next
After completing configuration of a full set of user groups, 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 authenticates orphaned users but most commands are not authorized.
SUMMARY STEPS
1.
2.
3.
or
secret {0 | 5} secret4.
5.
6.
or
commitDETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
username user-name
Example:RP/0/RP0/CPU0:router(config)# username user1
Creates a name for a new user (or identifies a current user) and enters username configuration submode.
•
Step 3
password {0 | 7} password
or
secret {0 | 5} secret
Example:RP/0/RP0/CPU0:router(config-un)# password 0 pwd1
or
RP/0/RP0/CPU0:router(config-un)# secret 0 sec1
Specifies a password for the user named in Step 2.
•
•
•
•
Step 4
group group-name
Example:RP/0/RP0/CPU0:router(config-un)# group sysadmin
Assigns the user named in Step 2 to a user group that has already been defined through the usergroup command.
•
•
Step 5
Repeat Step 4 for each user group to be associated with the user specified in Step 2.
—
Step 6
end
or
commit
Example:RP/0/RP0/CPU0:router(config-un)# end
or
RP/0/RP0/CPU0:router(config-un)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
What to Do Next
After completing configuration of a full set of users, configure router to use the RADIUS server communication or TACACS+ servers (See the "Configuring Router to RADIUS Server Communication" or "Configuring a TACACS+ Server" section.)
Configuring Router to RADIUS Server Communication
This task configures router to RADIUS server communication.
The RADIUS host is normally a multiuser system running RADIUS server software from Cisco (CiscoSecure ACS), Livingston, Merit, Microsoft, or another software provider. Configuring router to RADIUS server communication can have several components:
•
•
•
•
•
•
RADIUS security servers are identified on the basis of their hostname or IP address, hostname and specific User Datagram Protocol (UDP) port numbers, or IP address and specific UDP port numbers. The combination of the IP address and UDP port numbers creates a unique identifier, allowing different ports to be individually defined as RADIUS hosts providing a specific AAA service. In other words, this unique identifier enables RADIUS requests to be sent to multiple UDP ports on a server at the same IP address. If two different host entries on the same RADIUS server are configured for the same service—for example, accounting—the second host entry configured acts as an automatic switchover backup to the first one. Using this example, if the first host entry fails to provide accounting services, the network access server tries the second host entry configured on the same device for accounting services. (The RADIUS host entries are tried in the order they are configured.)
A RADIUS server and a Cisco router use a shared secret text string to encrypt passwords and exchange responses.To configure RADIUS to use the AAA security commands, you must specify the host running the RADIUS server daemon and a secret text (key) string that it shares with the router.
The timeout, retransmission, and encryption key values are configurable globally for all RADIUS servers, on a per-server basis, or in some combination of global and per-server settings. To apply these settings globally to all RADIUS servers communicating with the router, use the three unique global commands: radius-server timeout, radius-server retransmit, and radius-server key. To apply these values on a specific RADIUS server, use the radius-server host command.
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
or
commit9.
DETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
radius-server host {hostname | ip-address} [auth-port port-number] [acct-port port-number] [timeout seconds] [retransmit retries] [key string]
Example:RP/0/RP0/CPU0:router(config)# radius-server host host1
Specifies the hostname or IP address of the remote RADIUS server host.
•
•
•
•
Note
Step 3
radius-server retransmit retries
Example:RP/0/RP0/CPU0:router(config)# radius-server retransmit 5
Specifies the number of times the Cisco IOS XR software searches the list of RADIUS server hosts before giving up.
•
Step 4
radius-server timeout seconds
Example:RP/0/RP0/CPU0:router(config)# radius-server timeout 10
Sets the number of seconds a router waits for a server host to reply before timing out.
•
Step 5
radius-server key {0 clear-text-key | 7 encrypted-key | clear-text-key}
Example:RP/0/RP0/CPU0:router(config)# radius-server key 0 samplekey
Sets the authentication and encryption key for all RADIUS communications between the router and the RADIUS daemon.
Step 6
radius source-interface type instance [vrf vrf-id]
Example:RP/0/RP0/CPU0:router(config)# radius source-interface POS 0/3/0/1
(Optional) Forces RADIUS to use the IP address of a specified interface or subinterface for all outgoing RADIUS packets.
•
The vrf keyword enables the specification on a per-VRF basis.
Step 7
Repeat Step 2 through Step 6 for each external server to be configured.
—
Step 8
end
or
commit
Example:RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
Step 9
show radius
Example:RP/0/RP0/CPU0:router# show radius
(Optional) Displays information about the RADIUS servers that are configured in the system.
What to Do Next
After configuring router to RADIUS server communication, configure RADIUS server groups. (See the "Configuring RADIUS Server Groups" section.)
Configuring RADIUS Dead-Server Detection
This task configures the RADIUS Dead-Server Detection feature.
The RADIUS Dead-Server Detection feature lets you configure and determine the criteria that is used to mark a RADIUS server as dead. If no criteria is explicitly configured, the criteria is computed dynamically on the basis of the number of outstanding transactions. The RADIUS dead-server detection configuration results in the prompt detection of RADIUS servers that have stopped responding. The prompt detection of nonresponding RADIUS servers and the avoidance of swamped and dead-to-live-to-dead-again servers result in less deadtime and quicker packet processing.
You can configure the minimum amount of time, in seconds, that must elapse from the time that the router last received a valid packet from the RADIUS server to the time the server is marked as dead. If a packet has not been received since the router booted, and there is a timeout, the time criterion is treated as though it was met.
In addition, you can configure the number of consecutive timeouts that must occur on the router before the RADIUS server is marked as dead. If the server performs both authentication and accounting, both types of packets are included in the number. Improperly constructed packets are counted as though they are timeouts. Only retransmissions are counted, not the initial transmission. For example, each timeout causes one retransmission to be sent.
Note
The radius-server deadtime command specifies the time, in minutes, for which a server is marked as dead, remains dead, and, after this period, is marked alive even when no responses were received from it. When the dead criteria are configured, the servers are not monitored unless the radius-server deadtime command is configured
SUMMARY STEPS
1.
2.
3.
4.
5.
or
commit6.
DETAILED STEPS
Configuring Per VRF AAA
The Per VRF AAA functionality enables AAA services to be based on VPN routing and forwarding (VRF) instances. The Provider Edge (PE) or Virtual Home Gateway (VHG) communicates directly with the customer's RADIUS server, which is associated with the customer's VPN, without having to go through a RADIUS proxy. Thus, ISPs can scale their VPN offerings more efficiently, because they no longer have to use RADIUS proxies and they can provide their customers with the flexibility they demand.
New Vendor-Specific Attributes (VSAs)
The Internet Engineering Task Force (IETF) draft standard specifies a method for communicating vendor-specific information between the network access server and the RADIUS server by using the vendor-specific attribute (attribute 26). Attribute 26 encapsulates vendor-specific attributes, thereby, allowing vendors to support their own extended attributes otherwise not suitable for general use.
The Cisco IOS XR RADIUS implementation supports one vendor-specific option using the format recommended in the specification. Cisco's vendor-ID is 9, and the supported option has vendor-type 1, which is named "cisco-avpair." The value is a string of the following format:
protocol : attribute sep value *"Protocol" is a value of the Cisco "protocol" attribute for a particular type of authorization. "Attribute" and "value" are an appropriate attribute-value (AV) pair defined in the Cisco TACACS+ specification, and "sep" is "=" for mandatory attributes and "*" for optional attributes. This definition allows the full set of features available for TACACS+ authorization to also be used for RADIUS.
Table 3 describes the VSAs that are now supported for Per VRF AAA.
Table 3 Supported VSAs1 for Per VRF AAA
rad-serv
string
Indicates the IP address, key, timeout, and retransmit number of a server and the group of the server.
The VSA syntax follows:
rad-serv=a.b.c.d [key SomeKey] [auth-port X] [acct-port Y] [retransmit V] [timeout W].Other than the IP address, all parameters are optional and are issued in any order. If the optional parameters are not specified, their default values are used.
The key cannot contain any spaces; for "retransmit V," "V" can range from 1 to 100; for "timeout W," the "W" can range from 1 to 1000.
rad-serv-vrf
string
Specifies the name of the VRF that is used to transmit RADIUS packets. The VRF name matches the name that was specified through the vrf command.
SUMMARY STEPS
1.
2.
3.
4.
5.
or
commitDETAILED STEPS
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 waits 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.
7.
8.
or
commit9.
DETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
tacacs-server host host-name port port-number
Example:RP/0/RP0/CPU0:router(config)# tacacs-server host 209.165.200.226 port 51
RP/0/RP0/CPU0:router(config-tacacs-host)#
Specifies a TACACS+ host server and optionally specifies a server port number.
•
Step 3
tacacs-server host host-name timeout seconds
Example:RP/0/RP0/CPU0:router(config-tacacs-host)# tacac s-server host 209.165.200.226 timeout 30
RP/0/RP0/CPU0:router(config)#
Specifies a TACACS+ host server and optionally specifies a timeout value that sets the length of time the AAA server will wait to receive a response from the TACACS+ server.
•
Step 4
tacacs-server host host-name key [0 | 7] auth-key
Example:RP/0/RP0/CPU0:router(config)# tacacs-server host 209.165.200.226 key 0 a_secret
Specifies a TACACS+ host server and optionally specifies an authentication and encryption key shared between the AAA server and the TACACS+ server.
•
•
•
•
Step 5
tacacs-server host host-name single-connection
Example:RP/0/RP0/CPU0:router(config)# tacacs-server host 209.165.200.226 single-connection
Prompts the router to multiplex all TACACS+ requests to this server over a single TCP connection. By default, a separate connection is used for each session.
Step 6
tacacs source-interface type instance
Example:RP/0/RP0/CPU0:router(config)# tacacs source-interface POS 0/4/0/0
(Optional) Specifies the source IP address of a selected interface for all outgoing TACACS+ packets.
•
Step 7
Repeat Step 2. through Step 5. for each external server to be configured.
—
Step 8
end
or
commit
Example:RP/0/RP0/CPU0:router(config)# end
or
RP/0/RP0/CPU0:router(config)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
Step 9
show tacacs
Example:RP/0/RP0/CPU0:router# show tacacs
(Optional) Displays information about the TACACS servers that are configured in the system.
What to Do Next
After configuring TACACS+ servers, configure TACACS+ server groups. (See the "Configuring TACACS+ Server Groups" section.)
Configuring RADIUS Server Groups
This task configures RADIUS server groups.
The user can enter one or more server commands. The server command specifies the hostname or IP address of an external RADIUS server along with port numbers. When configured, this server 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.
6.
7.
or
commit8.
DETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
aaa group server radius group-name
Example:RP/0/RP0/CPU0:router(config)# aaa group server radius radgroup1
Groups different server hosts into distinct lists and enters the server group configuration mode.
Step 3
server {hostname | ip-address} [auth-port port-number] [acct-port port-number]
Example:RP/0/RP0/CPU0:router(config-sg-radius)# server 192.168.20.0
Specifies the hostname or IP address of an external RADIUS server.
•
Step 4
Repeat Step 3 for every external server to be added to the server group named in Step 2.
—
Step 5
server-private {hostname | ip-address} [auth-port port-number] [acct-port port-number] [timeout seconds] [retransmit retries] [key string]
Example:RP/0/RP0/CPU0:router(config-sg-radius)# server- private 10.10.130.2 auth-port 1600 acct-port 1666 key code
Configures the IP address of the private RADIUS server for the group server.
Note
Step 6
deadtime minutes
Example:RP/0/RP0/CPU0:router(config-sg-radius)# deadtime 1
Configures the deadtime value at the RADIUS server group level.
•
The example specifies a one-minute deadtime for RADIUS server group radgroup1 when it has failed to respond to authentication requests for the deadtime command
Note
Step 7
end
or
commit
Example:RP/0/RP0/CPU0:router(config-sg-radius)# end
or
RP/0/RP0/CPU0:router(config-sg-radius)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
Step 8
show radius server-groups [group-name [detail]]
Example:RP/0/RP0/CPU0:router# show radius server-groups
(Optional) Displays information about each RADIUS server group that is configured in the system.
What to Do Next
After configuring RADIUS server groups, define method lists by configuring authentication, authorization, and accounting. (See the "Configuring AAA Method Lists" section.)
Configuring TACACS+ Server Groups
This task configures TACACS+ server groups.
The user can enter one or more server commands. The server command specifies the hostname or IP address of an external TACACS+ server. Once configured, this server 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
commit6.
DETAILED STEPS
Step 1
configure
Example:RP/0/RP0/CPU0:router# configure
Enters global configuration mode.
Step 2
aaa group server tacacs+ group-name
Example:RP/0/RP0/CPU0:router(config)# aaa group server tacacs+ tacgroup1
Groups different server hosts into distinct lists and enters the server group configuration mode.
Step 3
server {hostname | ip-address}
Example:RP/0/RP0/CPU0:router(config-sg-tacacs+)# server 192.168.100.0
Specifies the hostname or IP address of an external TACACS+ server.
•
Step 4
Repeat Step 3 for every external server to be added to the server group named in Step 2.
—
Step 5
end
or
commit
Example:RP/0/RP0/CPU0:router(config-sg-tacacs+)# end
or
RP/0/RP0/CPU0:router(config-sg-tacacs+)# commit
Saves configuration changes.
•
Uncommitted changes found, commit them before exiting (yes/no/cancel)? [cancel]:–
–
–
•
Step 6
show tacacs server-groups
Example:RP/0/RP0/CPU0:router# show tacacs server-groups
(Optional) Displays information about each TACACS+ server group that is configured in the system.
What to Do Next
After configuring TACACS+ server groups, define method lists by configuring authentication, authorization, and accounting. (See the "Configuring AAA Method Lists" section.)
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 RADIUS or TACACS+), in sequence. The method will be one of the following:
•
•
•
•
If the method is RADIUS or TACACS+ servers, rather than server group, the RADIUS or TACACS+ server is chosen from the global pool of configured RADIUS and 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 the request is rejected.
Restrictions
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.
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.
Note
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. Cisco IOS XR software supports four types of AAA authorization:
•
Note
•
Note
•
•
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:
•
•
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 for each line or interface.
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.
Note
Accounting Configuration
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.
Creation of a Series of Accounting Methods
Use the aaa accounting command to create default or named method lists defining specific accounting methods that can be used for each line or interface.
The Cisco IOS XR software supports the following methods for accounting:
•
•
•
SUMMARY STEPS
1.
2.
{none | method}3.
or
commitDETAILED STEPS
What to Do Next
After configuring method lists, apply those method lists. (See the "Applying Method Lists for Applications" section.)
Generating Interim Accounting Records
This task enables periodic interim accounting records to be sent to the accounting server. When the aaa accounting update command is activated, Cisco IOS XR software issues interim accounting records for all users on the system.
Note
SUMMARY STEPS
1.
2.
3.
or
commitDETAILED STEPS
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, auxiliary, 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 example:
•
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 tacacs+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-taskgroup command with tga specified as the taskgroup-name argument ensures that such users are given the taskmap of the task group tga.
aaa default-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
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
—
To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Technical Assistance
