Cisco Network Function Virtualization Infrastructure Software Configuration Guide, Release 26.2 and Later

PDF

Cisco Network Function Virtualization Infrastructure Software Configuration Guide, Release 26.2 and Later

Users, roles, and authentication

Updated: June 29, 2026

Want to summarize with AI?

Describes how to configure user accounts, assign roles with specific permissions, and set up authentication methods to control access to network devices and management systems.

Configure local user account management

Configure role-based access control to enable administrators to manage different levels of access to the system's compute, storage, database, and application services using access control concepts such as users, groups, and rules.

Role based access enables the administrator to manage different levels of access to the system's compute, storage, database, and application services. It uses the access control concepts such as users, groups, and rules, which you can apply to individual API calls. You can also keep a log of all user activities.

Table 1. Supported user roles and privileges
User Role	Privilege
Administrators	Owns everything, can perform all tasks including changing user roles, but cannot delete basic infrastructure. An admin's role can't be changed
Operators	Start, stop, and delete a VM. Clear logs and view all information
Auditors	Read-only permission and can't perform any tasks

Before you begin

The user passwords must meet these requirements:

Must have at least seven characters length or the minimum required length configured by the admin user.
Must not have more than 128 characters.
Must contain a digit.
Must contain one of the following special characters: hash (#), underscore (_), hyphen (-), asterisk (*), or question mark (?).
Must contain an uppercase character and a lowercase character.
Must not be the same as last five passwords.

Procedure

	1.	Create a user and assign a role. The administrator can create users and define user roles as required. You can assign a user to a particular user group. For example, the user "test1" can be added to the user group "administrators". Example: `rbac authentication users create-user name test1 password Test1_pass role administrators`
	2.	Delete a user if needed. Example: `rbac authentication users delete-user name test1` Note To change the password, use the rbac authentication users user test1 change-password new-password newPassword old-password oldPassword command. To change the user role to administrators, operators or auditors, use the rbac authentication users user test1 change-role new-role newRole old-role oldRole command.
	3.	Configure the minimum length for passwords. The admin user can configure the minimum length required for passwords of all users. The minimum length must be between 7 to 128 characters. By default, the minimum length required for passwords is set to 7 characters. Example: `configure terminal rbac authentication min-pwd-length 10 commit`
	4.	Configure password lifetime values. The admin user can configure minimum and maximum lifetime values for passwords of all users and enforce a rule to check these values. The default minimum lifetime value is set to 1 day and the default maximum lifetime value is set to 60 days. When a minimum lifetime value is configured, the user cannot change the password until the specified number of days have passed. Similarly, when a maximum lifetime value is configured, a user must change the password before the specified number of days pass. If a user does not change the password and the specified number of days have passed, a notification is sent to the user. Note The minimum and maximum lifetime values and the rule to check for these values are not applied to the admin user. Example: `configure terminal rbac authentication password-lifetime enforce true min-days 2 max-days 30 commit`
	5.	Configure automatic deactivation of inactive user accounts. The admin user can configure the number of days after which an unused user account is marked as inactive and enforce a rule to check the configured inactivity period. When marked as inactive, the user cannot login to the system. To allow the user to login to the system, the admin user can activate the user account by using the rbac authentication users user username activate command. Note The inactivity period and the rule to check the inactivity period are not applied to the admin user. Example: `configure terminal rbac authentication account-inactivity enforce true inactivity-days 2 commit`
	6.	Activate an inactive user account when needed. The admin user can activate the account of an inactive user. Example: `configure terminal rbac authentication users user guest_user activate commit`

Local user account management is configured with role-based access control, password requirements, and account lifecycle management policies.

User and role management in the NFVIS portal

User and role management in the NFVIS portal is a graphical interface that

provides an intuitive alternative to command-line operations for managing user accounts and roles
enables administrators to create, modify, and delete user accounts, and
allows assignment of specific roles to define user access levels within the system.

Create new users

Create new user accounts in NFVIS portal to provide controlled access to system resources based on assigned roles and permissions.

Use this procedure when you need to grant access to the NFVIS system for new team members or when setting up role-based access control for different user types.

Before you begin

Follow these steps to create a new user account through the NFVIS portal:

Procedure

Navigate to Configuration > Host > Security > Users and Roles.

From the Users and Roles page, click the + icon to create a new user.

Enter the following details:


Field	Description
Name	Enter the unique login name for the new user account..
Role	Select the predefined role that defines the user's permissions and access level within the NFVIS system. Options typically include: Administrator: Full access to configure, update, or delete resources, and manage user roles. Operator: Can view, start, stop, and delete Virtual Machines (VMs). Auditor: Read-only access to system information.
Password	Enter the password for the new user account. This must comply with the configured strong password policies (e.g., minimum length, complexity requirements including uppercase, lowercase, numbers, and special characters).
Confirm Password	Re-enter the password exactly as entered in the Password field to confirm accuracy and prevent typing errors.
Group	Choose a user group to assign this user to. User groups are used for granular role-based access control (RBAC) and can define specific access policies for sets of users or resources.
Preferred Language	Choose the default language for a user's NFVIS portal interface: English Japanese When this user logs in, the NFVIS portal will be displayed in the language chosen here.

Click Submit to create the new user account with the specified details and save the configuration.

Click Cancel to discard any entered information and return to the previous screen without creating the user.
Click Reset to clear all fields on the form, allowing you to re-enter information.

The new user account is created with the specified role, permissions, and configuration settings. The user can now log in to the NFVIS portal using the assigned credentials.

Modify users

Modify user account details such as role, password, group, and preferred language to maintain proper access control and user management.

User accounts may need to be updated periodically to reflect changes in user roles, security requirements, or personal preferences. This task allows administrators to modify existing user accounts through the NFVIS portal interface.

Before you begin

Follow these steps to modify a user account through the NFVIS portal:

Procedure

	1.	Navigate to Configuration > Host > Security > Users and Roles.
	2.	From the Users and Roles page, click the edit icon to modify an existing user account. When modifying a user account, you can update details such as their Role, password, Group, and Preferred Language.
	3.	Click Submit to apply the changes and save the updated configuration. Click Cancel to discard any changes and return to the previous screen without modifying the user. Click Reset to clear all fields on the form, allowing you to re-enter information.

The user account is successfully updated with the new configuration details, and the changes are saved in the system.

Delete users

Delete user accounts to remove access and manage security within the NFVIS portal.

Use this procedure when you need to remove user accounts from the NFVIS system through the portal interface.

Before you begin

Follow these steps to delete users through the NFVIS portal:

Procedure

Navigate to Configuration > Host > Security > Users and Roles.

From the Users and Roles page, identify the user account you want to delete and click the Delete icon associated with it.

A confirmation message is displayed to confirm the deletion of the user account.

In the confirmation dialog, use the following options:

Delete: Click this button to proceed with the permanent deletion of the selected user account(s).
Cancel: Click this button to abort the deletion process and return to the "Users and Roles" page without removing the user(s).

The selected user account is permanently deleted from the NFVIS system.

Change language preferences in the NFVIS portal

Configure the NFVIS portal interface language to support user interaction in their preferred language (English or Japanese).

Cisco NFVIS portal now supports both English and Japanese languages, providing users with the flexibility to interact with the interface in their preferred language.

Users can adjust their language preferences through two ways methods within the NFVIS portal:

From the current user session, using the Settings icon.
From the Users and Roles page. For more information on setting the default language for user accounts, see Create New Users.

Before you begin

Follow these steps to change the language for your current portal session:

Procedure

	1.	Log in to the NFVIS portal
	2.	Click the user profile icon.
	3.	From the drop-down menu, choose Language Preferences
	4.	Choose your desired language (English or Japanese) from the available options. Once a language is chosen, the portal interface will immediately update to the chosen language, and a confirmation notification will appear. This change applies only to your current session.

The portal interface displays in your selected language for the current session.

User groups

Granular Role-Based access control

Restrictions for granular Role-Based access control

When configuring granular role-based access control, observe these restrictions to ensure proper system operation:

A group can only be associated with one policy, either the resource-access-control policy or the local-authentication-only policy.
One user can be assigned to one group only.
A VM can only belong to one group.

Granular role-based access control

Granular Role-Based Access Control (Granular RBAC) is a security feature that

restricts VM management to a particular set of users
enables system administrators to define resource groups and assign VNFs and system resources to these groups, and
allows user assignment to resource groups for access to associated VNFs.

Resource management components

The system administrator can define a set of resource groups, and assign VNFs and system resources such as VMs, disk files, and system level configurations to these defined groups. When you create a user, you can assign that user to one of the resource groups, and this enables the user to access the associated VNFs.

Roles

The three roles defined by the system are:

Administrator: An administrator user has complete access to configure, update or delete a resource.
Operator: An operator user can only view and operate a resource.
Auditor: An auditor user can only view a resource and cannot perform any action on it.

Note

All three roles have a read-access to all host level configurations, VMs, and images.

Users

A user is an account that

is created with a role definition that is consistent across all groups
has read access to NFVIS configurations, filesystems, logs, VMs and images
can be a member of only one group, and
may have remote authentication mapping for TACACS and RADIUS based on privilege level.

Admin user characteristics

The admin user is a special user account with unique properties:

The admin user cannot be deleted or modified.
The admin user permanently has the administrator role in the default global group.
The admin user functions as a member of every group and can execute administrative privileges for every group.
The admin user cannot be assigned to a specific user group.

Groups

A group is a collection of users that

provides access control to resources based on membership
defines resource assignment boundaries where a resource can belong to one specific group, and
ensures all members have access to the resources assigned to that group, with privileges defined by the user's role.

Group types and characteristics

The global group is a special group assigned to users who are not members of any other group. A user in the global group can access all resources on the system, at the privilege level.

Resources can be assigned to the global group or a specific group.

When creating a group, the resource-access-control policy should be enabled, to have resource restrictions.

For more details on Granular RBAC feature capabilities, see Appendix.

Create groups and assign local users to the groups

This task allows you to establish role-based access control by creating groups and assigning local users to them, enabling organized user management and policy enforcement.

Groups provide a way to organize users and apply policies for role-based access control (RBAC). You can create groups with or without specific policies and then assign local users to these groups to manage their access permissions.

Procedure

Create a group with or without a policy.

Example:

nfvis(config)# aaa groups group rac_group policy resource-access-control
nfvis(config-policy-resource-access-control)# commit
Commit complete.

Create a local user and assign them to a group.

Example:

nfvis# rbac authentication users create-user name local_admin_3 password Cisco123\# role administrators group rac_group

View a list of RBAC users with role and group information.

Example:

nfvis# show running-config rbac authentication users
rbac authentication users user admin
 role administrators
!
rbac authentication users user local_admin_1
 role administrators
!
rbac authentication users user local_admin_2
 role administrators
!
rbac authentication users user local_admin_3
 role administrators
 groups group rac_group
 !
!
rbac authentication users user local_oper_1
 role operators
!
rbac authentication users user local_test_1
 role operators
!

The groups are created and local users are assigned to them. You can verify the configuration by viewing the RBAC users with their associated roles and groups.

Assign remote users to the group

Assign remote users to a resource control group so they can manage deployments based on their defined role in the remote server.

NFVIS depends on a remote server for user authentication and authorization. When remote users login to NFVIS, they can only manage the deployment that belongs to its own resource control group, based on their defined role in the remote server. Any remote user that is not mentioned in the resource group, is treated as a global group user and that user can operate the system and manage the deployments based on their defined role.

Procedure

Assign remote users to the group using the following commands:

Example:


nfvis(config)# aaa groups group tac_group user remote_admin1
nfvis(config-user-remote_admin1)# user remote_admin2
nfvis(config-user-remote_admin2)# user remote_operator3
nfvis(config-user-remote_operator3)# policy resource-access-control
nfvis(config-policy-resource-access-control)# commit
Commit complete.
nfvis(config-policy-resource-access-control)# end
nfvis# show running-config aaa groups group tac_group
aaa groups group tac_group
policy resource-access-control
!
user remote_admin1
!
user remote_admin2
!
user remote_operator3
!
!
nfvis#
nfvis# show rbac authentication users
NAME
-------
admin

Note

In the above example, remote_admin1, remote_admin2, and remote_operator3 are TACACS+/RADIUS users.

Remote users are successfully assigned to the resource control group and can manage deployments according to their defined roles.

Configure local authentication for a specific group of users

This task enables you to create a group and add specific users to it, allowing these users to bypass the default authentication order and only go through local authentication instead of the default TACACS then local authentication sequence.

Typically, users who need authentication go through the default authentication order. The default order involves external authentication through TACACS as the first step, and local authentication as the second step. The local authentication for a specific group of users feature enables you to create a group and add specific users to it, allowing these users to bypass the default authentication order. The users in this group skip the external TACACS authentication and only go through local authentication. For this group to function as expected, assign the 'local-authentication-only' policy to the group.

Restrictions for local authentication for a specific group of users:

One user can be assigned to a maximum of one group.
If a local user assigned to the local authentication group has the same user name as a remote (TACACS+/RADIUS) user, then only the local user's credentials are taken into consideration. The remote user's credentials are considered even if the local user's authentication fails.

Procedure

Create a group with the local-authentication-only policy.

Example:

nfvis#(config) aaa groups group [ group-name ] policy local-authentication-only

Assign a user to the group using one of these methods:

Assign an existing user to the group:

nfvis# rbac authentication users user <username> assign-group [ group-name ]

Create a new user and assign to the group simultaneously:

nfvis# rbac authentication users create-user name <username> password <password> role <role> group [ group-name ]

To remove a user from a group, use:

nfvis# rbac authentication users user <username> remove-group [ group-name ]

The group is created with the local-authentication-only policy, and the specified users are assigned to the group. These users will now bypass external TACACS authentication and only go through local authentication.

RADIUS support

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed client-server system that

secures networks against unauthorized access
uses Cisco routers as RADIUS clients that send authentication requests to a central RADIUS server containing all user authentication and network service access information, and
operates as a fully open protocol distributed in source code format that can be modified to work with any security system currently available on the market.

RADIUS implementation details

Cisco supports RADIUS under its AAA security paradigm. RADIUS has been implemented in a variety of network environments that require high levels of security while maintaining network access for remote users.

Note

You can configure upto four RADIUS servers. When multiple RADIUS servers are configured, if the first server is unreachable, NFVIS tries the next server in the order it is configured.

How RADIUS authentication works

Summary

The key components involved in RADIUS authentication are:

User: Provides credentials and receives authentication responses
Access server: Prompts for credentials and relays authentication requests
RADIUS server: Validates credentials and provides authorization data

Workflow

These stages describe how RADIUS authentication works:

The user is prompted to enter the username and PASSWORD.
The username and encrypted PASSWORD are sent over the network to the RADIUS server.
The user receives one of these responses from the RADIUS server:
- ACCEPT—The user is authenticated.
- 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.
- REJECT—The user is not authenticated and is prompted to reenter the username and PASSWORD, or access is denied.

Result

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 services that the user can access, including connections such as Telnet, rlogin, or local-area transport (LAT), and services such as PPP, Serial Line Protocol (SLIP), or EXEC services, and connection parameters, including the host or client IP address, access list, and user timeouts.

Configure RADIUS

This task configures RADIUS authentication to enable secure client-server communication with encrypted secret key support.

RADIUS secret encryption is supported on NFVIS. You can configure either secret key or encrypted secret key at a given time. Use encrypted secret if special characters are used in secret. NFVIS encrypts both shared-secret and encrypted-shared-secret configurations and supports both TLS and non-TLS client-server communication for RADIUS.

Secret length must be between 1 and 127 characters.
Secret must only contain characters from the set: [-_a-zA-Z0-9 ./\<>%!*$€#{}()+@]*

Procedure

Configure RADIUS support using one of the following methods:

For non-TLS RADIUS configuration, use these commands:

configure terminal
radius-server host 1.2.3.4
shared-secret abc
admin-priv 15
oper-priv 11
commit

For TLS RADIUS configuration, use these commands:

configure terminal
radius-server host 1.2.3.4
shared-secret efkbkuabcwuabvauvvwqbd
use-tls true
pskidentity identity
admin-priv 15
oper-priv 11
commit

Verify the RADIUS configuration using the show running-config RADIUS-server command.

Example:


nfvis# show running-config radius-server radius-server host 1.2.3.4
shared-secret $8$lZwgccBvs9x1oQpx6f1s8/JkZ4rLdQ95VMUjRrhD9Z8=
admin-priv    15
oper-priv     11

The shared secret is displayed in encrypted form.

RADIUS authentication is successfully configured with encrypted secret key support for secure client-server communication.

TACACS+ support

TACACS+

TACACS+ is a security application that

provides centralized validation of users attempting to gain access to a router or network access server
maintains services in a database on a TACACS+ daemon running, typically, on a UNIX or Windows NT workstation, and
requires TACACS+ server configuration before the configured TACACS+ features on your network access server are available.

TACACS+ server configuration requirements

On the TACACS+ server, ensure you configure Cisco attribute-value (AV) pair privilege level (priv-lvl) for Cisco NFVIS as a service for the minimum privilege level of administrators and operators.

Note

You can configure upto four TACACS+ servers. When multiple TACACS+ servers are configured, if the first server is unreachable, NFVIS tries the next server in the order it is configured.

How TACACS operates

Summary

The key components involved in TACACS operation are:

User: Attempts to log in to NFVIS using credentials
NFVIS: Sends user credentials to TACACS+ server and processes responses
TACACS+ server: Authenticates users and provides authorization responses

Workflow

The TACACS operation involves these stages:

When the user tries to log in, NFVIS sends user credential to TACACS+ server.
NFVIS will eventually receive one of the following responses from the TACACS+ server:
- ACCEPT—The user is authenticated and service can begin. If NFVIS is configured to require authorization, authorization begins at this time.
- REJECT—The user is not authenticated. The user can be denied access or is prompted to retry the login sequence, depending on the TACACS+ server.
- ERROR—An ERROR occurred at some time during authentication with the server or in the network connection between the server and NFVIS. If an ERROR response is received, NFVIS typically tries to use an alternative method for authenticating the user.
- CONTINUE—The user is prompted for additional authentication information.
After authentication, NFVIS will send authorization request to TACACS+ server.
Based on authorization result, NFVIS will assign user's role.

Configure a TACACS+ server

Configure TACACS+ server authentication to enable centralized user authentication and authorization with customizable privilege levels for different user roles.

TACACS+ secret encryption is supported. You can only configure either secret key or encrypted secret key at a given time. Encrypted secret key can contain special characters but secret key cannot. The following pattern is supported for encryped-shared-key: [-_a-zA-Z0-9./\\<>%!*$€#{}()+].

NFVIS encrypts both shared-secret and encrypted-shared-secret configurations.

NFVIS supports both TLS and non-TLS client-server communication for TACACS+.

The following constraints apply:

Secret length must be between 1 and 127 characters.
Secret must only contain characters from the set: [-_a-zA-Z0-9 ./\<>%!*$€#{}()+@]*

Procedure

	1.	Configure TACACS+ without TLS. Example: `configure terminal tacacs-server host 1.2.3.4 shared-secret asdfghh admin-priv 14 oper-priv 9 commit` In this configuration, privilege level 14 is assigned to the administrator role, and privilege level 9 is assigned to the operator role. This means a user with privilge level 14 or higher will have all admin privileges when the user logs into the system, and a user with privilege level 9 or higher will have all privileges of an operator at the time of login.
	2.	Configure TACACS+ with TLS. Example: `configure terminal tacacs-server host 1.2.3.4 shared-secret mfqwudvkdwnbkyuDLndkw use-tls true pskidentity identity admin-priv 14 oper-priv 9 commit`
	3.	Verify the TACACS+ configuration. Example: `nfvis# show running-config tacacs-server tacacs-server host 1.2.3.4 shared-secret $8$JkMZFgA3DkbjAHOrmdBr3U2cLg2qY1FuHAIJiIp7nSw= admin-priv 14 oper-priv 9` Use the show running-config TACACS-server command to verify the configuration. The shared secret is displayed in encrypted form.

The TACACS+ server is configured with the specified host, shared secret, and privilege levels. Users can now authenticate through the TACACS+ server with appropriate role-based privileges.

Default authentication order

Default authentication order is a security mechanism that

supports both TACACS+ and RADIUS but allows only one authentication method to be enabled at a time
requires method lists to be defined for TACACS+ and RADIUS authentication through AAA commands, and
uses local authentication as fallback when TACACS+ or RADIUS is not accessible.

Authentication configuration

After you have identified the TACACS+ and RADIUS server and defined an associated TACACS+ and RADIUS authentication key, you must define method lists for TACACS+ and RADIUS authentication. Because TACACS+ and RADIUS authentication is operated through AAA, you need to issue the AAA authentication command, specifying TACACS+ or RADIUS as the authentication method.


nfvis(config)# aaa authentication ?
Possible completions:
  radius   Use RADIUS for AAA
  tacacs   Use TACACS+ for AAA
  users    List of local users

Note

Only when TACACS+ or RADIUS is enabled, it can be used for authentication.

When TACACS+ or RADIUS is not accessible, local authentication is used. It is recommended to use AAA authentication TACACS local command to authenticate using local database. Local authentication is disabled if the connection between TACACS+ or RADIUS and NFVIS is restored.

If the same username is registered for both local authentication and authentication through RADIUS or TACACS+, RADIUS or TACACS+ is chosen as the authentication method.

It is recommended to configure Syslog so that it is easier to debug if TACACS+ or RADIUS does not work as expected.

All login attempts will be logged in syslogs in the local nfvis_syslog.log, NFVIS-ext-auth.log files and in remote syslog servers.

User specific authentication order

The system follows this authentication sequence for user-specific authentication:

If the user is part of the local database, local authentication is executed and the user is permitted or denied access.
If the user is not part of the local database, TACACS+ is used for authentication.
If the same user is part of both the databases (local and TACACS+), the user can login with either the local password or the TACACS+ password. However, registering the same user in both the databases is not recommended.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.