Overview on AAA Services
This section lists all the conceptual information that a 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
User attributes form the basis of the Cisco software administrative model. Each router user is associated with the following attributes:
-
User ID (ASCII string) that identifies the user uniquely across an administrative domain
-
Length limitation of 253 characters for passwords and one-way encrypted secrets
-
List of user groups (at least one) of which the user is a member (thereby enabling attributes such as task IDs).
User Categories
Router users are classified into the following categories:
-
Root Secure Domain Router (SDR) user (specific SDR administrative authority)
-
SDR user (specific SDR user access)
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:
-
Configure secure domain routers.
-
Create, delete, and modify root SDR users (after logging in to the secure domain router as the root system user).
-
Create, delete, and modify secure domain router users and set user task permissions (after logging in to the secure domain router as the root system user).
-
Access fabric racks or any router resource not allocated to a secure domain router, allowing the root system user to authenticate to any router node regardless of the secure domain router configurations.
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:
-
Create, delete, and modify secure domain router users and their privileges for the SDR.
-
Create, delete, and modify user groups to allow access to the SDR.
-
Manage nearly all aspects of the SDR.
A root SDR user cannot deny access to a root system user.
Secure Domain Router (SDR) Users
A SDR user has restricted access to an SDR as determined by the root SDR user. The SDR user performs the day-to-day system and network management activities. The tasks that the secure domain router user is allowed to perform are determined by the task IDs associated with the user groups to which the SDR user belongs. Multiple SDRs in a chasis are not supported.
User Groups
A user group defines a collection of users that share a set of attributes, such as access privileges. Cisco software allows the system administrator to configure groups of users and the job characteristics that are common in groups of users. Users are not assigned to groups by default hence the assignment needs to be done explicitly. A user can be assigned to more than one group.
Each user may be associated with one or more user groups. User groups have the following attributes:
-
A user group consists of the list of task groups that define the authorization for the users. All tasks, except cisco-support, are permitted by default for root system users.
-
Each user task can be assigned read, write, execute, or debug permission.
Predefined User Groups
The Cisco software provides a collection of user groups whose attributes are already defined. The predefined groups are as follows:
-
cisco-support: This group is used by the Cisco support team.
-
maintenance: Has the ability to display, configure and execute commands for network, files and user-related entities.
-
netadmin: Has the ability to control and monitor all system and network parameters.
-
operator: A demonstration group with basic privileges.
-
provisioning: Has the ability to display and configure network, files and user-related entities.
-
read-only-tg: Has the ability to perform any show command, but no configuration ability.
-
retrieve: Has the ability to display network, files and user-related information.
-
root-lr: Has the ability to control and monitor the specific secure domain router.
-
serviceadmin: Service administration tasks, for example, Session Border Controller (SBC).
-
sysadmin: Has the ability to control and monitor all system parameters but cannot configure network protocols.
To verify the individual permissions of a user group, assign the group to a user and execute the show user tasks command.
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, a change in group B affects group A, even if the group is not reinherited explicitly.
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.
Predefined Task Groups
The following predefined task groups are available for administrators to use, typically for initial configuration:
-
cisco-support: Cisco support personnel tasks
-
netadmin: Network administrator tasks
-
operator: Operator day-to-day tasks (for demonstration purposes)
-
root-lr: Secure domain router administrator tasks
-
sysadmin: System administrator tasks
-
serviceadmin: Service administration tasks, for example, SBC
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. 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.
Command Access in XR and Admin Modes
The XR user group and task is mapped to the System Admin VM group when the System Admin mode is accessed from XR mode using admin command. The corresponding access permission on System Admin VM is available to the user. Currently, only aaa, admin task and root-lr groups are mapped to System Admin VM group or task. The other tasks like protocols are not mapped as these services are not supported in System Admin VM. The disaster-recovery user of System Admin VM is synced with the Host VM.
|
XR Task or Group |
Sysadmin VM Group |
Access |
Example |
|---|---|---|---|
|
root-lr |
Root-system group |
Full access to the system configuration. |
|
|
Admin-r/w/x/d |
Admin-r |
Read only commands on Sysadmin VM |
|
|
Netadmin or sysadmin group Admin-r/ wx /d, aaa -r/w/x/d |
Aaa -r and admin -r |
Read only commands on Sysadmin VM |
|
Admin Access for NETCONF and gRPC Sessions
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Admin Access for NETCONF and gRPC Sessions |
Release 7.4.1 |
This feature allows all authorized users on XR VM to access administration data on the router through NETCONF or gRPC interface, similar to accessing the CLI. This functionality works by internally mapping the task group of the user on XR VM to a predefined group on System Admin VM. Therefore, the NETCONF and gRPC users can access the admin-related information on the router even if their user profiles do not exist on System Admin VM. Prior to this release, only those users who were authorized on XR VM could access System Admin VM through CLI, by using the admin command. Users that were not configured on System Admin VM were denied access through the NETCONF or gRPC interfaces. |
NETCONF is an XML-based protocol used over Secure Shell (SSH) transport to configure a network. Similarly, gRPC is an open-source remote procedure call framework. The client applications can use these protocols to request information from the router and make configuration changes to the router. Prior to Cisco IOS XR Software Release 7.4.1, users who use NETCONF, gRPC or any other configuration interface, other than CLI, to access the admin-related information on the router, had to belong to user groups that are configured on System Admin VM. Otherwise, the router would issue an UNAUTHORIZED access error message and deny access through that client interface.
By default, XR VM synchronizes only the first-configured user to System Admin VM. If you delete the first-user in XR VM, the system synchronizes the next user in the root-lr group (which is the highest privilege group in XR VM for Cisco IOS XR 64-bit platforms) to System Admin VM only if there are no other users configured in System Admin VM. The system does not automatically synchronize the subsequent users to System Admin VM. Therefore, in earlier releases, users whose profiles did not exist in System Admin VM were not able to perform any NETCONF or gRPC operations on System Admin VM.
From Cisco IOS XR Software Release 7.4.1 and later, the system internally maps the users who are authorized on XR VM to System Admin VM of the router, based on the task table of the user on XR VM. With this feature, the NETCONF and gRPC users can access admin-related information on the router even if their user profiles do not exist on System Admin VM. By default, this feature is enabled.
To know more about NETCONF and gRPC operations, see the Use NETCONF Protocol to Define Network Operations with Data Models chapter and Use gRPC Protocol to Define Network Operations with Data Models chapter in the Programmability Configuration Guide for Cisco NCS 5500 Series Routers.
User Profile Mapping from XR VM to System Admin VM
User privileges to execute commands and access data elements on the router are usually specified using certain command rules and data rules that are created and applied on the user groups.
For details on user groups, command rules and data rules, see the Create User Profiles and Assign Privilege chapter in the System Setup and Software Installation Guide for Cisco NCS 5500 Series Routers.
When the internal process for AAA starts or when you create the first user, the system creates the following set of predefined groups, command rules and data rules in System Admin VM. These configurations are prepopulated to allow users of different groups (such as root-system , admin-r and aaa-r ) in System Admin VM.
You can use the show running-configuration aaa command to view the AAA configurations.
aaa authentication groups group aaa-r gid 100 users %%__system_user__%%
!
aaa authentication groups group admin-r gid 100 users %%__system_user__%%
!
aaa authentication groups group root-system gid 100 users "%%__system_user__%% "
!
aaa authorization cmdrules cmdrule 1 context * command * group root-system ops rx action accept
!
aaa authorization cmdrules cmdrule 2 context * command "show running-config aaa" group aaa-r ops rx action accept
!
aaa authorization cmdrules cmdrule 3 context * command "show tech-support aaa" group aaa-r ops rx action accept
!
aaa authorization cmdrules cmdrule 4 context * command "show aaa" group aaa-r ops rx action accept
!
aaa authorization cmdrules cmdrule 5 context * command show group admin-r ops rx action accept
!
aaa authorization datarules datarule 1 namespace * context * keypath * group root-system ops rwx action accept
!
aaa authorization datarules datarule 2 namespace * context * keypath /aaa group aaa-r ops r action accept
!
aaa authorization datarules datarule 3 namespace * context * keypath /aaa group admin-r ops rwx action reject
!
aaa authorization datarules datarule 4 namespace * context * keypath / group admin-r ops r action accept
!
The admin CLI for the user works based on the above configurations. The root-system is the group with the highest privilege in System Admin VM. The admin-r group has only read and execute access to all data. The aaa-r group has access only to AAA data. With the introduction of the admin access feature for all users, the NETCONF and gRPC applications can also access the admin data based on the above rules and groups.
User Profile Mapping Based on Task-ID
This table shows the internal mapping of XR VM users to System Admin VM. The users in XR VM belong to various user groups such as aaa , admin , root-lr and root-system .
|
XR VM User Group:Task-ID |
System Admin VM User Group |
|---|---|
| aaa:rwxd | aaa-r |
| aaa:rwx | aaa-r |
| aaa:rw | aaa-r |
| aaa:wx | aaa-r |
| aaa:rx | aaa-r |
| aaa:r | aaa-r |
| aaa:w | aaa-x |
| aaa:x | aaa-x |
| root-system:rwxd | root-system |
| root-lr:rwxd | root-system |
| admin:rwxd | admin-r |
| admin:rwx | admin-r |
| admin:rw | admin-r |
| admin:r | admin-r |
How to Allow Read Access to Administration Data for NETCONF and gRPC Clients
NETCONF and gRPC users access the administration data on the router through GET operations as defined by the respective protocols. To allow this read access to administration data for users belonging to admin-r group, you must configure a new command rule specifically for the NETCONF or gRPC client.
Configuration Example
Router#admin
sysadmin-vm:0_RP0#configure
sysadmin-vm:0_RP0(config)#aaa authorization cmdrules cmdrule 6
sysadmin-vm:0_RP0(config-cmdrule-6)#context netconf
sysadmin-vm:0_RP0(config-cmdrule-6)#command get
sysadmin-vm:0_RP0(config-cmdrule-6)#group admin-r
sysadmin-vm:0_RP0(config-cmdrule-6)#ops rx
sysadmin-vm:0_RP0(config-cmdrule-6)#action accept
sysadmin-vm:0_RP0(config)#commit
Running Configuration
aaa authorization cmdrules cmdrule 6
context netconf
command get
group admin-r
ops rx
action accept
!
Associated Command
-
aaa authorization (System Admin-VM)
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.
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.
-
Configuring authentication that uses remote AAA servers that are not available, particularly authentication for the console.
 Note |
The none option without any other method list is not supported. |
-
Configuring command authorization or XR EXEC mode authorization on the console should be done with extreme care, because TACACS+ servers may not be available or may deny every command, which locks the user out. This lockout can occur particularly if the authentication was done with a user not known to the TACACS+ server, or if the TACACS+ user has most or all the commands denied for one reason or another.
To avoid a lockout, we recommend these:
-
Before turning on TACACS+ command authorization or XR EXEC mode authorization on the console, make sure that the user who is configuring the authorization is logged in using the appropriate user permissions in the TACACS+ profile.
-
If the security policy of the site permits it, use the none option for command authorization or XR EXEC mode authorization so that if the TACACS+ servers are not reachable, AAA rolls over to the none method, which permits the user to run the command.
-
Make sure to allow local fallback when configuring AAA. See, Create Series of Authorization Methods.
-
If you prefer to commit the configuration on a trial basis for a specified time, you may do so by using the commit confirmed command, instead of direct commit .
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 |
The database is local to the specific secure domain router (SDR) in which it is stored, and the defined users or groups are not visible to other SDRs in the same system. |
You can delete the last remaining user from the local database. If all users are deleted when the next user logs in, the setup dialog appears and prompts you for a new username and password.
Note |
The setup dialog appears only when the user logs into the console. |
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.
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 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:
-
Local: Use the locally configured database (not applicable for accounting and certain types of authorization)
-
TACACS+: Use a TACACS+ server (such as CiscoSecure ACS)
-
RADIUS: Use a RADIUS server
-
Line: Use a line password and user group (applicable only for authentication)
-
None: Allow the request (not applicable for authentication)
Note |
If the system rejects the authorization request and the user gets locked out, you can try to rollback the previous configuration or remove the problematic AAA configuration through auxiliary port. To log in to the auxiliary port, use the local username and password; not the tacacs+ server credentials. The config_rollback -n 0x1 command can be used to rollback the previous configuration. If you are not able to access the auxiliary port, a router reload might be required in such scenarios. |
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 XR EXEC mode).
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 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 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.
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, the user is authenticated as a secure domain router user.
Authentication Flow of Control
AAA performs authentication according to the following process:
-
A user requests authentication by providing a username and password (or secret).
-
AAA verifies the user’s password and rejects the user if the password does not match what is in the database.
-
AAA determines the role of the user (root SDR user, or SDR user).
-
If the user has been configured as a member of an owner secure domain router user group, then AAA authenticates the user as an owner secure domain router user.
-
If the user has not been configured as a member of an owner secure domain router user group, AAA authenticates the user as a secure domain router user.
Clients can obtain a user’s permitted task IDs during authentication. This information is obtained by forming a union of all task group definitions specified in the user groups to which the user belongs. Clients using such information typically create a session for the user (such as an API session) in which the task ID set remains static. Both the XR EXEC mode and external API clients can use this feature to optimize their operations. XR EXEC mode can avoid displaying the commands that are not applicable and an EMS application can, for example, disable graphical user interface (GUI) menus that are not applicable.
If the attributes of a user, such as user group membership and, consequently, task permissions, are modified, those modified attributes are not reflected in the user’s current active session; they take effect in the user’s next session.
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 login. For applications such as PPP, the two-way encrypted password is used even if a secret is present.
Type 8 and Type 9 Passwords
This feature provides the options for Type 8 and Type 9 passwords in AAA security services. The Type 8 and Type 9 passwords provide more secure and robust support for saving passwords w.r.t each username. Thus, in scenarios where a lot of confidential data need to be maintained, these encryption methods ensure that the admin and other user passwords are strongly protected.
The implementation of Type 8 password uses SHA256 hashing algorithm, and the Type 9 password uses scrypt hashing algorithm.
Note |
The Type 8 and Type 9 passwords are supported on the IOS XR 64-bit operating system starting from Cisco IOS XR Software Release 7.0.1. |
Type 10 Password
The Cisco IOS XR 64-bit software introduces the support for Type 10 password that uses SHA512 encryption algorithm. The SHA512 encryption algorithm provides improved security to the user passwords compared to the older algorithms such as MD5 and SHA256 . With this feature, SHA512 becomes the default encryption algorithm for the passwords in user name configuration, even for the first user creation scenario. Prior to the introduction of Type 10 password, MD5 was used as the default algorithm.
To configure Type 10 password, see Configure Type 10 Password.
Restrictions for Type 10 Password Usage
These restrictions apply to the usage of Type 10 password:
-
Backward compatibility issues such as configuration loss, authentication failure, and so on, are expected when you downgrade to lower versions that still use MD5 or SHA256 encryption algorithms. Convert the passwords to Type 10 before such downgrades to minimize the impact of such issues. For details, see Backward Compatibility for Password Types.
-
In a first user configuration scenario or when you reconfigure a user, the system syncs only the Type 5 and Type 10 passwords from XR VM to System Admin VM and Host VM. It doesn't sync the Type 8 and Type 9 passwords in such scenarios.
AAA Password Security for FIPS Compliance
Cisco IOS XR Software introduces advanced AAA password strengthening policy and security mechanism to store, retrieve and provide rules or policy to specify user passwords. This password policy is applicable only for local users, and not for remote users whose profile information are stored in a third party AAA server. This policy is not applicable to secrets of the user. If both secret and password are configured for a user, then secret takes precedence, and password security policy does not have any effect on authentication or change of password for such users. This AAA password security policy works as such for Cisco IOS XR platforms. Whereas, this feature is supported only on XR VM, for Cisco IOS XR 64 bit platforms and Cisco NCS 5500 Series Routers.
High Availability for AAA Password Security Policy
The AAA password policy configurations and username configurations remain intact across RP failovers or process restarts in the system. The operational data such as, lifetime of the password and lockout time of the user are not stored on system database or disk. Hence, those are not restored across RP failovers or process restarts. Users start afresh on the active RP or on the new process. Hence, users who were locked out before RP failover or process restart are able to login immediately after the failover or restart.
To configure AAA password policy, see Configure AAA Password Policy.
AAA Password Security Policies
AAA password security for FIPS compliance consists of these policies:
Password Composition Policy
Passwords can be composed by any combination of upper and lower case alphabets, numbers and special characters that include: "!", "@", "#", "$", "%", "^", "&", "*", "(", and ")". Security administrator can also set the types and number of required characters that comprise the password, thereby providing more flexibility for password composition rules. The minimum number of character change required between passwords is 4, by default. There is no restriction on the upper limit of the number of uppercase, lowercase, numeric and special characters.
Password Length Policy
The administrator can set the minimum and maximum length of the password. The minimum configurable length in password policy is 2, and the maximum length is 253.
Password Lifetime Policy
The administrator can configure a maximum lifetime for the password, the value of which can be specified in years, months, days, hours, minutes and seconds. The configured password never expires if this parameter is not configured. The configuration remains intact even after a system reload. But, the password creation time is updated to the new time whenever the system reboots. For example, if a password is configured with a life time of one month, and if the system reboots on 29th day, then the password is valid for one more month after the system reboot. Once the configured lifetime expires, further action is taken based on the password expiry policy (see the section on Password Expiry Policy).
Password Expiry Policy
If the password credential of a user who is trying to login is already expired, then the following actions occur:
-
User is prompted to set the new password after successfully entering the expired password.
-
The new password is validated against the password security policy.
-
If the new password matches the password security policy, then the AAA data base is updated and authentication is done with the new password.
-
If the new password is not compliant with the password security policy, then the attempt is considered as an authentication failure and the user is prompted again to enter a new password. The max limit for such attempts is in the control of login clients and AAA does not have any restrictions for that.
As part of password expiry policy, if the life time is not yet configured for a user who has already logged in, and if the security administrator configures the life time for the same user, then the life time is set in the database. The system checks for password expiry on the subsequent authentication of the same user.
Password expiry is checked only during the authentication phase. If the password expires after the user is authenticated and logged in to the system, then no action is taken. The user is prompted to change the password only during the next authentication of the same user.
Debug logs and syslog are printed for the user password expiry only when the user attempts to login. This is a sample syslog in the case of password expiry:
RP/0/RSP1/CPU0:Jun 21 09:13:34.241 : locald_DSC[308]: %SECURITY-LOCALD-5-USER_PASSWD_EXPIRED :
Password for user 'user12' has expired.
Password Change Policy
Users cannot change passwords at will. A password change is triggered in these scenarios:
-
When the security administrator needs to change the password
-
When the user is trying to get authenticated using a profile and the password for the profile is expired
-
When the security administrator modifies the password policy which is associated to the user, and does not immediately change the password according to the policy
You can use the show configuration failed command to display the error messages when the password entered does not comply with the password policy configurations.
When the security administrator changes the password security policy, and if the existing profile does not meet the password security policy rules, no action is taken if the user has already logged in to the system. In this scenario, the user is prompted to change the password when he tries to get authenticated using the profile which does not meet the password security rules.
When the user is changing the password, the lifetime of the new password remains same as that of the lifetime that was set by the security administrator for the old profile.
When password expires for non-interactive clients (such as dot1x), an appropriate error message is sent to the clients. Clients must contact the security administrator to renew the password in such scenarios.
Service Provision after Authentication
The basic AAA local authentication feature ensures that no service is performed before a user is authenticated.
User Re-authentication Policy
A user is re-authenticated when he changes the password. When a user changes his password on expiry, he is authenticated with the new password. In this case, the actual authentication happens based on the previous credential, and the new password is updated in the database.
User Authentication Lockout Policy
AAA provides a configuration option, authen-max-attempts , to restrict users who try to authenticate using invalid login credentials. This option sets the maximum number of permissible authentication failure attempts for a user. The user gets locked out when he exceeds this maximum limit, until the lockout timer ( lockout-time ) is expired. If the user attempts to login in spite of being locked out, the lockout expiry time keep advancing forward from the time login was last attempted.
This is a sample syslog when user is locked out:
RP/0/RSP1/CPU0:Jun 21 09:21:28.226 : locald_DSC[308]: %SECURITY-LOCALD-5-USER_PASSWD_LOCKED :
User 'user12’ is temporarily locked out for exceeding maximum unsuccessful logins.
This is a sample syslog when user is unlocked for authentication:
RP/0/RSP1/CPU0:Jun 21 09:14:24.633 : locald_DSC[308]: %SECURITY-LOCALD-5-USER_PASSWD_UNLOCKED :
User 'user12' is unlocked for authentications.
Password Policy Creation, Modification and Deletion
Security administrators having write permission for AAA tasks are allowed to create password policy. Modification is allowed at any point of time, even when the policy is associated to a user. Deletion of password policy is not allowed until the policy is un-configured from the user.
After the modification of password policy associated with a user, security administrator can decide if he wants to change passwords of associated users complying to the password policy. Based on this, there are two scenarios:
-
If the administrator configures the password, then the user is not prompted to change the password on next login.
-
If the administrator does not configure the password, then the user is prompted to change the password on next login.
In either of the above cases, at every password expiry interval, the user is prompted to change the password on next login.
Debug messages are printed when password policies are created, modified and deleted.
Minimum Password Length for First User Creation
To authenticate the user for the first time, Cisco router prompts you to create a username and password, in any of the following situations:
-
When the Cisco Router is booted for the very first time.
-
When the router is reloaded with no username configuration.
-
When the already existing username configurations are deleted.
By default, the minimum length for passwords in a Cisco router is limited to two characters. Due to noise on the console, there is a possibility of the router being blocked out. Therefore, the minimum length for password has been increased to six characters for a first user created on the box, in each of the situations described above. This reduces the probability of the router being blocked out. It avoids the security risks that are caused due to very small password length. For all other users created after the first one, the default minimum length for password is still two characters.
For more information about how to configure a first user, see Configure First User on Cisco Routers.
Password Policy for User Secret
The Cisco IOS XR Software extends the existing password policy support for the user authentication to all types of user secret. The types of secret include Type 5 (MD5 ), 8 (SHA256 ), 9 (sCrypt ) and 10 (SHA512 ). Prior to this release, the support for password policy was only for the Type 7 passwords. The new policy is common to both password and secret of the user. Using irreversible hashed-secrets has the benefit that the other modules in the device cannot retrieve the clear-text form of these secrets. Thus, the enhancement provides more secure secrets for the user names. This policy for user secrets is applicable for local and remote users.
The classic Cisco IOS XR platforms support the password policy for secrets on the XR and the Admin plane. Whereas, the 64-bit Cisco IOS XR platforms support this feature only on XR VM; not on System Admin VM.
To configure password policy for user secret, see Configure Password Policy for User Secret and Password.
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 software by a task-based authorization system.
Task IDs
The operational tasks that enable users to control, configure, and monitor Cisco 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
Most router control, configuration, or monitoring operation (CLI, Netconf, Restconf, XML API) is associated with a particular set of task IDs. Typically, a given CLI command or API invocation is associated with at least one or more task IDs. Neither the config nor the commit commands require any specific task id permissions. The configuration and commit operations do not require specific task ID permissions. Aliases also don't require any task ID permissions. You cannnot perform a configuration replace unless root-lr permissions are assigned. If you want to deny getting into configuration mode you can use the TACACS+ command authorization to deny the config command. 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 this table.
Note |
Restconf will be supported in a future release. |
|
Operation |
Description |
|---|---|
|
Read |
Specifies a designation that permits only a read operation. |
|
Write |
Specifies a designation that permits a change operation and implicitly allows a read operation. |
|
Execute |
Specifies a designation that permits an access operation; for example ping and Telnet. |
|
Debug |
Specifies a designation that permits a debug operation. |
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/write, execute) 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 no value specified, the command is used without any previous association to a task ID and operation. In addition, users do not have 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 redundancy
Task IDs for TACACS+ and RADIUS Authenticated Users
Cisco software AAA provides the following means of assigning task permissions for users authenticated with the TACACS+ and RADIUS methods:
-
Specify the text version of the task map directly in the configuration file of the external TACACS+ and RADIUS servers.
-
Specify the privilege level in the configuration file of the external TACACS+ and RADIUS servers.
-
Create a local user with the same username as the user authenticating with the TACACS+ and RADIUS methods.
-
Specify, by configuration, a default task group whose permissions are applied to any user authenticating with the TACACS+ and RADIUS methods.
Privilege 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 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 = bar
service = 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.
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:
-
Authentication, Authorization and Accounting configuration
-
User, user group, and task group configuration
-
TACACS+ server and server group configuration
-
RADIUS server and server group configuration
Netconf and Restconf for AAA Services
Just as in XML schemas, in Netconf and Restconf, username and password is controlled by either local or triple A (AAA) services.
Note |
Restconf will be supported in a future release. |
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 is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms. |
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:
-
Networks with multiple-vendor access servers, each supporting RADIUS. For example, access servers from several vendors use a single RADIUS server-based security database. In an IP-based network with multiple vendors’ access servers, dial-in users are authenticated through a RADIUS server that has been customized to work with the Kerberos security system.
-
Turnkey network security environments in which applications support the RADIUS protocol, such as in an access environment that uses a “smart card” access control system. In one case, RADIUS has been used with Enigma security cards to validate users and grant access to network resources.
-
Networks already using RADIUS. You can add a Cisco router with RADIUS to the network. This might be the first step when you make a transition to a Terminal Access Controller Access Control System Plus (TACACS+) server.
-
Networks in which a user must access only a single service. Using RADIUS, you can control user access to a single host, utility such as Telnet, or protocol such as Point-to-Point Protocol (PPP). For example, when a user logs in, RADIUS identifies this user as having authorization to run PPP using IP address 10.2.3.4 and the defined access list is started.
-
Networks that require resource accounting. You can use RADIUS accounting independent of RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of services, indicating the amount of resources (such as time, packets, bytes, and so on) used during the session. An Internet service provider (ISP) might use a freeware-based version of RADIUS access control and accounting software to meet special security and billing needs.
-
Networks that support preauthentication. Using the RADIUS server in your network, you can configure AAA preauthentication and set up the preauthentication profiles. Preauthentication enables service providers to better manage ports using their existing RADIUS solutions and to efficiently manage the use of shared resources to offer differing service-level agreements.
Network Security Situations in Which RADIUS is Unsuitable
RADIUS is not suitable in the following network security situations:
- Multiprotocol access
environments. RADIUS does not support the following protocols:
-
NetBIOS Frame Control Protocol (NBFCP)
-
NetWare Asynchronous Services Interface (NASI)
-
X.25 PAD connections
-
-
Router-to-router situations. RADIUS does not provide two-way authentication. RADIUS can be used to authenticate from one router to a router other than a Cisco router if that router requires RADIUS authentication.
-
Networks using a variety of services. RADIUS generally binds a user to one service model.
RADIUS Operation
When a user attempts to log in and authenticate to an access server using RADIUS, the following steps occur:
-
The user is prompted for and enters a username and password.
-
The username and encrypted password are sent over the network to the RADIUS server.
-
The user receives one of the following responses from the RADIUS server:
-
ACCEPT—The user is authenticated.
-
REJECT—The user is not authenticated and is prompted to reenter the username and password, or access is denied.
-
CHALLENGE—A challenge is issued by the RADIUS server. The challenge collects additional data from the user.
-
CHANGE PASSWORD—A request is issued by the RADIUS server, asking the user to select a new password.
The ACCEPT or REJECT response is bundled with additional data used for XR EXEC mode 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:
-
-
Services that the user can access, including Telnet, rlogin, or local-area transport (LAT) connections, and PPP, Serial Line Internet Protocol (SLIP), or XR EXEC mode services.
-
Connection parameters, including the host or client IP address, access list, and user timeouts.
RADIUS with TLS protection
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
RADIUS with TLS protection |
Release 24.4.1 |
Remote Authentication Dial-In User Service (RADIUS) over Transport Layer Security (TLS) or RADSEC is now supported on Cisco IOS XR NCS 540 routers. You can configure the RADIUS protocol on the Cisco router (RADIUS client) to redirect RADIUS packets to a remote RADIUS server connected over TLS for Authentication, Authorization, and Accounting (AAA) services. Without TLS, RADIUS packets may be subject to potential security vulnerabilities, including data exposure, replay attacks, weak authentication, and encryption vulnerabilities, especially when transmitted across untrusted networks. The feature introduces these changes: CLI:
YANG Data Models:
(see GitHub, YANG Data Models Navigator) |
Topology for RADIUS with TLS protection
Traditionally, RADIUS has been used for Authentication, Authorization, and Accounting (AAA). However, to meet modern security demands it is important to enhance its encryption and authentication. To increase the resilience against threats and maintain a secure network environment, TLS is now utilized as the transport protocol for RADIUS.
This feature supports TLS version 1.3.
Let's understand how you can establish RADIUS communication with TLS.
Establish TLS session: The RADIUS client initiates the process to establish a secure TLS session with the RADIUS server, which acts as the TLS server. This session is built upon a TCP socket that the RADIUS client creates.
Store TLS context: Upon successful TLS connection, the TLS context is preserved within the TLS connection context. This, in turn, is stored within the RADIUS context for the specified server, ensuring a persistent secure environment for subsequent communications.
RADIUS packet handling: The format of the RADIUS packet remains consistent with that used in RADIUS over TCP. The application constructs a RADIUS packet using standard methods. Instead of sending it via a TCP socket, the packet is handed over to the TLS layer for secure encapsulation. TLS effectively becomes the transport layer for RADIUS, hence the designation "RADIUS/TLS."
Secure data transmission: The RADIUS packets are securely transmitted over the TLS layer with data encryption/decryption.
This approach ensures that the RADIUS communications are secure, especially in roaming environments where the packets may pass through various administrative domains and untrusted networks. TLS provides a robust security layer, addressing the vulnerabilities associated with traditional RADIUS over UDP.
Optimized RADIUS session control:
-
To manage RADIUS sessions effectively, the RADIUS client employs Path MTU discovery before initiating traffic.
-
The RADIUS client avoids using the same source socket for both RADIUS/UDP and RADIUS/TLS traffic to different servers.
-
Once a TLS session is established, TLS heartbeats monitor connectivity with the server.
-
Additionally, an application-layer watchdog algorithm checks server responsiveness. The client proactively closes idle sessions; sessions indicated as inactive by the TLS heartbeat, or those with only watchdog traffic for three timeouts.
-
RADIUS sessions are terminated when RADIUS packets fail validation or contain invalid authenticators. When a session fails validation, the session is validated again using the next specified failover mechanism.
Restrictions for RADIUS with TLS Protection
The list provides the restrictions that apply to RADIUS with TLS protection:
-
Broadband Network Gateway (BNG) applications are not supported.
-
The default destination port for RADIUS over TLS is TCP 2083 for authentication and accounting. There is no support for custom ports.
-
The maximum number of concurrent TLS sessions supported is 50.
-
RADIUS over TLS supports IPv4 addresses only.
-
A combination of TLS, UDP, and DTLS server types under one server group over RADIUS is not recommended.
Supported ciphers
TLS ciphers are encryption algorithms that secure RADIUS traffic. Here are some supported TLS ciphers:
-
TLS_AES_256_CGM_SHA384
-
TLS_CHACHA20_POLY1305_SHA256
-
TLS_AES_128_CGM_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_256_CGM_SHA384
-
TLS_ECDHE_RSA_WITH_AES_256_CGM_SHA384
-
TLS_DHE_RSA_WITH_AES_256_CGM_SHA384
-
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
-
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
-
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
-
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
-
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
-
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
-
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
-
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
-
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
-
TLS_RSA_WITH_AES_256_GCM_SHA384
-
TLS_RSA_WITH_AES_128_GCM_SHA256
-
TLS_RSA_WITH_AES_256_CBC_SHA256
-
TLS_RSA_WITH_AES_128_CBC_SHA256
-
TLS_RSA_WITH_AES_256_CBC_SHA
-
TLS_RSA_WITH_AES_128_CBC_SHA
-
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
The cipher suite negotiated between the client and the server when both support TLS 1.3 is:
-
TLS_AES_256_GCM_SHA384
Configure RADIUS with TLS protection
To configure RADIUS with TLS protection, use the command radius-server host with keyword radsec-server .
Before you begin
Before configuring RADIUS with TLS protection, complete these steps on the Cisco router. See Implementing Certification Authority Interoperability for more information.
-
Configure a trustpoint.
-
Import the CA certificate.
-
Enroll the trustpoint and generate a client certificate on CA.
-
Import the client certificate.
Procedure
|
Step 1 |
Enter the hostname or IP address of the RADIUS server. |
|
Step 2 |
Enter the name of the trusted point so that the router can verify certificates issued to peers. Your router need not enroll with the CA that issued the certificates to the peers. |
|
Step 3 |
Commit the changes. |
|
Step 4 |
Verify that TLS is enabled by using the show radius command. |
|
Step 5 |
Verify the configuration settings by using the show running-configuration command. |
Hold-Down Timer for TACACS+
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Hold-Down Timer for TACACS+ |
Release 7.4.1 |
TACACS+ servers provide AAA services to the user. When a TACACS+ server becomes unreachable, the router sends the client request to another server, leading to considerable delay in addressing requests. To prevent this delay, you can set a hold-down timer on the router. The timer gets triggered after the router marks the TACACS+ server as down. During this period, the router does not select the server that is down for processing any client requests. When the timer expires, the router starts using that TACACS+ server for client transactions. This feature improves latency in providing AAA services to the user by limiting the client requests from being sent to unresponsive servers. This feature introduces the holddown-time command. |
The TACACS+ server is a AAA server with which the router communicates to provide authentication, authorization, and accounting services for users. When a TACACS+ server goes down, the router is not made aware. After sending a AAA request, the client waits for a response from the server for a configured timeout. If the router does not receive a response within that time frame, it sends the request to the next available server or discards the request if no other servers are available. A new request also needs to follow the same procedure in the same order of servers. The overall process results in sending multiple requests to servers that are down and therefore delays the client request from reaching an active server.
With the TACACS+ hold-down timer feature, you can mark an unresponsive TACACS+ server as down, and also set a duration for which the router does not use that server for further client transaction. After the timer expires, the router starts using that server again for processing client requests. This feature in turn allows you to control the participation of a TACACS+ server in AAA functions, without removing the TACACS+ server configuration from the router.
The hold-down timer value, in seconds, ranges from 0 to 1200. To enable hold-down timer, use the holddown-time command under the various configuration modes listed in the How to Configure Hold-Down Timer for TACACS+ section.
How Does the Hold-Down Timer for TACACS+ Function?
The following image depicts the functionality of TACACS+ hold-down timer.
When a TACACS+ client request comes, the router selects a TACACS+ server and checks whether that server is marked as down. If the server is marked as down, the router selects another server until it finds an available server. If the server is not marked as down, the router sends the client request to that server. If the router does not receive an acknowledgment message from the server, it marks that server as down and initiates the hold-down timer. After the timer expires, an internal server probe begins, which checks the connectivity of the down server. The probe tries to connect to the server every 20 seconds, for a maximum of three times (these values are non-configurable). If connection is successful in any of these attempts, then the router marks that server as up, and ends the server probe. Even if the connection fails on all retries of the server probe, the router still marks the server as up before exiting the server probe. After exiting the server probe, the router considers that server as available again to accept client requests.
If an unresponsive server is still not reachable after the hold-down timer expiry, then the system continues to regard that server as being down, and does not use it for client transactions for some more time (that is, approximately, one minute). The router starts using that server again for further client transactions only after this short delay.
In case the TACACS+ server comes up while the hold-down timer continues, the router continues to consider that server as down until the timer expires.
Feedback