System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

System Security Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

AAA administrative models

Updated: September 18, 2026

Want to summarize with AI?

Log in

Explains AAA administrative models, emphasizing secure practices, database integration, remote configuration elements, server groups, authentication workflows, and essential guidelines for protecting administrative access and handling system reload scenarios.

A AAA administrative model is a secure-domain access model that

  • assigns AAA configuration, local user, group, TACACS+, and RADIUS settings to each secure domain router

  • provides isolation so users created in one secure domain router cannot access others unless configured in those domains, and

  • ensures each router operates within its own secure domain plane for granular control and security.

Caution: Protect administrative access during AAA configuration

To avoid loss of administrative access during AAA configuration, follow these cautionary measures:

  • Do not configure authentication using remote AAA servers that may be unavailable, especially for console access.

  • The "none" option without any other method list is not supported.

  • Avoid configuring command authorization or XR EXEC mode authorization on the console without careful planning. If TACACS+ servers are unreachable or deny all commands, you may be locked out. This is especially true if authentication uses a user not recognized by the TACACS+ server or if command authorization restricts most commands.

  • Ensure you log in with appropriate user permissions in the TACACS+ profile before enabling TACACS+ command authorization or XR EXEC mode authorization on the console.

  • If permitted by your site’s security policy, use the "none" option for command authorization or XR EXEC mode authorization so that the AAA configuration automatically falls back to this method if TACACS+ servers become unreachable.

  • Always enable local fallback when configuring AAA. For details, see the AAA password security and authorization policies chapter.

  • When committing configuration changes, use the "commit confirmed" command instead of "commit" to allow a timed trial and reduce the risk of accidental lockout.

AAA databases

AAA databases are repositories that

  • store users, groups, and task information that control access to the system

  • can be configured as either local or remote databases, and

  • support different operational and fallback behaviors based on their configuration.

Additional reference information

Local AAA databases reside on the device itself and provide access control directly. Remote AAA databases use external servers, such as RADIUS or TACACS+, to authenticate, authorize, and account for users and tasks. The AAA configuration determines which database is leveraged for a particular authentication or authorization request.

AAA database sources

AAA data can be stored locally in a secure domain router or remotely in an external security server.

Table 1. AAA database source behavior

Source

Behavior

Local database

Stores users, user groups, and task groups locally within an SDR. Data is stored in the in-memory database and persists in the configuration file. The stored passwords are encrypted.

Local database SDR scope

Data is local to the SDR where it is stored. Defined users or groups are not visible to other SDRs in the same system.

Local database setup dialog

If all users are deleted, the setup dialog appears and prompts for a new username and password at the next console login. The setup dialog appears only for console login.

Remote database

Stores AAA data in an external security server, such as CiscoSecure ACS. A client such as a network access server can use the data when it has the server IP address and shared secret.

Use the source behavior details to choose the primary AAA database and appropriate local fallback behavior for your deployment.

Remote AAA configuration elements

Products such as CiscoSecure ACS can administer the shared or external AAA database.

Table 2. Remote AAA configuration elements

Element

Requirement or behavior

Remote server protocol

The router communicates with the remote AAA server by using a standard IP-based security protocol, such as TACACS+ or RADIUS.

Client configuration

Configure the security server with the secret key shared with the router and with the client IP addresses.

External user groups

External TACACS+ or RADIUS user groups are managed independently. The router does not recognize the external user group structure.

Remote profiles

Remote user or group profiles can contain attributes that specify router-defined groups and individual task IDs.

External task groups

Task ID definitions may need external software support before external task groups are configured. Task IDs can also be configured in external TACACS+ or RADIUS servers.

Additional information

Use the server product documentation for external user group configuration, as this configuration is specific to each server product design.

AAA method lists and server groups

The following table describes the core elements of AAA configuration:

Table 3. AAA configuration elements

Element

Behavior

Method lists

Method lists define the preferred order for AAA data sources. AAA can define more than one method list, and applications such as login can select a list.

Default method list behavior

Console ports can use one method list while vty ports use another. If a method list is not specified, the application tries the default method list. If no default method list exists, AAA uses the local database.

Server grouping

Administrators can form server groups for AAA protocols such as RADIUS and TACACS+ and associate them with AAA applications such as PPP and XR EXEC mode.

TACACS+ server-group fallback

If one TACACS+ server in a group is unreachable, the system uses the next server in that group. If the shared secret does not match, the router bypasses that group and uses the next configured method.

Use method lists and server groups to keep different access applications aligned with the intended AAA source order.

How AAA rollover works

AAA can use a prioritized list of database options for authentication, authorization, and accounting requests.

Summary

The key components involved in the process are:

  • AAA subsystem: Handles authentication, authorization, and accounting requests.

  • Database methods: Includes local, TACACS+, RADIUS, line, and none as options for processing requests.

  • Prioritized method list: Determines the order in which methods are attempted.

AAA uses a prioritized list of database methods for authentication, authorization, and accounting. If a method is unavailable, AAA automatically rolls over to the next method. If any method rejects a request, AAA stops the rollover and rejects the request.

Workflow

These stages describe how AAA rollover works.

  1. AAA receives an authentication, authorization, or accounting request.

  2. AAA tries the first configured method in the prioritized method list.

  3. If the method is unavailable, AAA rolls over to the next configured method.

  4. If a method rejects the request, AAA does not roll over and rejects the request.

  5. Available methods include local, TACACS+, RADIUS, line, and none. Local does not apply to accounting and certain authorization types. Line applies only to authentication. None does not apply to authentication.

Result

When authorization rejection locks out a user, you may need to roll back the previous configuration or remove the problematic AAA configuration through the auxiliary port. Use the local username and password for auxiliary-port login, and run the config_rollback -n 0x1 command to revert to the previous configuration. If auxiliary-port access is unavailable, a router reload might be required.

How AAA authentication works

Authentication is the security process by which a principal, such as a user or application, obtains access to the system.

Summary

The key components involved in the process are:

  • User: Provides credentials to request access and is assigned a role.

  • AAA system: Authenticates credentials and determines user roles and task group membership.

  • SDR user groups: Define user roles and access permissions within the system.

  • Clients (XR EXEC mode or external API clients): Use task IDs to optimize operations and enforce available commands or GUI menus.

AAA authentication is the security mechanism by which a principal, such as a user or application, obtains access to the system. AAA verifies credentials, determines roles and access levels, and associates users with permitted tasks.

Workflow

These stages describe how AAA authentication works.

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

  2. AAA verifies the user's password and rejects the user if the password does not match the database value.

  3. AAA determines whether the user role is root SDR user or SDR user.

  4. If the user is configured as a member of an owner SDR user group, AAA authenticates the user as an owner SDR user.

  5. If the user is not configured as a member of an owner SDR user group, AAA authenticates the user as an SDR user.

  6. Clients can obtain the user's permitted task IDs by forming a union of all task group definitions in the user's user groups.

  7. XR EXEC mode and external API clients can use the task-ID set to optimize operations, such as hiding unavailable commands or disabling unavailable GUI menus.

Result

When user attributes or task permissions change, modifications do not affect the user's current active session. The changes take effect in the user's next session.

Log in to the auxiliary port after system reload with remote AAA authentication

If you configure TACACS+ or RADIUS authentication for AAA and reload the system, your first login attempt to the RP auxiliary port may fail—even when you enter a valid TACACS+ username and password.

This happens because, immediately after a reload, the auxiliary port rejects TACACS+ login attempts. To recover, follow these steps:

  • Log in with a valid locally configured username and password for your initial login after reload.

  • After successfully logging in locally, you can use your TACACS+ username and password for subsequent logins.

  • If you access the auxiliary port via a terminal server, clear the terminal server line first. Then log in using your TACACS+ username and password.

Sample AAA configuration:

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