Role based access control (RBAC) controls user access to commands and resources based on user role. This chapter describes the basic idea of RBAC and guides you through the RBAC configuration procedure.

Overview

On devices that support multiple users, RBAC is used to assign command and resource access permissions to user roles that are created for different job functions. Users are given permission to access a set of commands and resources based on their user roles. Because user roles are persistent, in contrast to users, separating permissions from users enables easy permission authorization management. When the job responsibilities of a user changes, new users are added, or old users are removed, you only need to change the user roles or assign new user roles.

Permission assignment

Assigning permissions to a user role includes the following:

· Define a set of rules to specify commands accessible or inaccessible to the user role. (See "User role rules.")

· Configure resource access policies to specify which interfaces, VLANs, and VPNs are accessible to the user role. (See "Resource access policies.")

To use a command related to a specific interface, VLAN, or VPN, a user role must have access to both the command and the interface, VLAN, or VPN.

For example, a user role has access to the qos apply policy command and access to only interface GigabitEthernet 3/0/1. With this user role, you can enter the interface view and use the qos apply policy command on the interface, but you cannot enter the view of any other interface or use the command on any other interface. If the user role has access to any interface but does not have access to the qos apply policy command, you cannot use the command on any interface.

User role rules

User role rules permit or deny access to commands. You can define the following types of rules for different access control granularities:

· Command rule—Controls access to a command or a set of commands that match a regular expression.

· Feature rule—Controls access to the commands of a feature by command type:

¡ Read—Commands that display configuration and maintenance information. Examples include the display commands and the dir command.

¡ Write—Commands that configure the feature in the system. Examples include the info-center enable command and the debugging command.

¡ Execute—Commands that execute specific functions. Examples include the ping command and the ftp command.

· Feature group rule—Controls access to commands of a group of features by command type.

A user role can have multiple rules uniquely identified by rule numbers. The set of permitted commands in these rules are accessible to the user role. If two rules conflict, the one with higher number takes effect. For example, if rule 1 permits the ping command, rule 2 permits the tracert command, and rule 3 denies the ping command, the user role can use the tracert command but not the ping command.

Resource access policies

Resource access policies control access of user roles to system resources and include the following types:

· Interface policy—Controls access to interfaces.

· VLAN policy—Controls access to VLANs.

· VPN instance policy—Controls access to VPNs.

Resource access policies do not control access to the interface, VLAN, or VPN options in the display commands. You can specify these options in the display commands if they are permitted by any user role rule.

Predefined user roles

The system provides 20 predefined user roles. All these user roles have access to all system resources (interfaces, VLANs, and VPNs), but their command access permissions (see Table 1) differ.

Among all the predefined user roles, only the user roles network-admin, mdc-admin, and level-15 can access the RBAC feature, and change the settings including user-role, authentication-mode, protocol, and set authentication password in user interface view.

All the predefined user roles are available for the default MDC. The user roles network-admin and network-operator are not available for non-default MDCs. For more information about MDCs, see "Configuring MDCs."

Table 1 Predefined roles and permissions matrix

User role name	Permissions
network-admin	Accesses all features and resources in the system.
network-operator	· Accesses the display commands (except display history-command all) for all features and resources in the system. · Switches between MDC views. · Enables local authentication login users to change their own password.
mdc-admin	Accesses all the features and resources in the administered MDC.
mdc-operator	· Accesses the display commands (except display history-command all) for all the features and resources available in the administered MDC. · Enables local authentication login users to change their own password.
level-n (n = 0 to 15)	· level-0—Has access to diagnostic commands, including ping and tracert. Level-0 access rights are configurable. · level-1—Has access to the display commands (except display history-command all) of all features and resources in the system, in addition to all access rights of the user role level-0. Level-1 access rights are configurable. · level-2 to level-8, and level-10 to level-14—Have no access rights by default. Access rights are configurable. · level-9—Has access to all features and resources except RBAC, local users, MDCs, file management, device management, and the display history-command all command. Level-9 access rights are configurable. · level-15—Has the widest set of access rights among all predefined user roles, except for network-admin. Level-15 has access to all features and resources except the following: ¡ Changing settings of local user accounts that have the user role of network-admin or network-operator. ¡ Changing the configuration in user interface view of the user that has the user role network-admin or network-operator, including user-role, authentication-mode, protocol, and set authentication password.

Assigning user roles

You assign access rights to users by assigning at least one user role. The users can use the collection of commands and resources accessible to any user role assigned to them. For example, user role A denies access to the qos apply policy command and permits access to only interface GigabitEthernet 3/0/1, and user role B permits access to the qos apply policy command and all interfaces. With these two user roles, you can access any interface to use the qos apply policy command.

Depending on the authentication method, user role assignment has the following approaches:

· AAA authorization—If scheme authentication is used, the AAA module handles user assignment.

¡ If the user passes local authorization, the device assigns the user roles specified in the local user account.

¡ If the user passes remote authorization, the remote AAA server assigns the user roles specified on the server. The AAA server can be a RADIUS or HWTACACS server.

· None-AAA authorization—If the user uses password authentication or no authentication, the device assigns user roles specified on the user interface. This approach also applies to SSH clients that use publickey or password-publickey authentication. User roles assigned to these SSH clients are specified in their respective local management user accounts.

For more information about AAA and SSH, see Security Configuration Guide. For more information about user interfaces, see "Login overview" and "Logging in to the CLI."

Configuration task list

Tasks at a glance
(Required.) Creating user roles
(Required.) Configuring user role rules
(Optional.) Configuring feature groups
(Optional.) Changing resource access policies
(Optional.) Assigning user roles
(Optional.) Configuring user role switching

Creating user roles

In addition to the predefined user roles, you can create up to 64 custom user roles for granular access control.

To create a user role:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a user role and enter user role view.	role name role-name	By default, the system has 20 predefined user roles: network-admin, network-operator, mdc-admin, mdc-operator, and level-n (where n equals an integer in the range 0 to 15). Among these user roles, only the permissions of the user roles level-0 to level-14 are configurable.
3. (Optional.) Configure a description for the user role.	description text	By default, a user role has no description.

Configuring user role rules

Configure command, feature, and feature group rules to permit or deny the access of a user role to specific commands. The configuration in the non-predefined user role view does not take effect for the MDC.

You can configure up to 256 rules for a user role, but the total number of user role rules in the system cannot exceed 1024.

If two rules of a user role conflict, the one with a higher rule number has priority.

Any rule modification, addition, or removal for a user role takes effect only on users that are logged in with the user role after the change.

To configure rules for a user role:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter user role view.	role name role-name	N/A
3. Configure a rule.	· Configure a command rule: rule number { deny \| permit } command command-string · Configure a feature rule: rule number { deny \| permit } { execute \| read \| write } * feature [ feature-name ] · Configure a feature group rule: rule number { deny \| permit } { execute \| read \| write } * feature-group feature-group-name	Configure at least one command. By default, a user-defined user role has no rules or access to any command. Repeat this step to add up to 256 rules to the user role. IMPORTANT: When you configure feature rules, you can specify only features available in the system and must enter feature names exactly the same as they are displayed, including the case.

Configuring feature groups

Use feature groups to bulk assign command access permissions to sets of features. In addition to the predefined feature groups, you can create up to 64 custom feature groups and assign a feature to multiple feature groups.

To configure a feature group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
1. Create a feature group and enter feature group view.	role feature-group name feature-group-name	By default, the system has the following predefined feature groups: · L2—Includes all Layer 2 protocol-specific commands. · L3—Includes all Layer 3 protocol-specific commands. These two groups are not user configurable.
2. Add a feature to the feature group.	feature feature-name	By default, a feature group has no features. IMPORTANT: You can specify only features available in the system and must enter feature names exactly the same as they are displayed, including the case.

Changing resource access policies

Every user role has one interface policy, VLAN policy, and VPN instance policy. By default, these policies permit user roles to access any interface, VLAN, and VPN. You can change the policies of user-defined user roles and the predefined level-n user roles to limit their access to interfaces, VLANs, and VPNs. A changed policy takes effect only on users that are logged in with the user role after the change.

Changing the interface policy of a user role

Step	Command	Remarks
3. Enter system view.	system-view	N/A
4. Enter user role view.	role name role-name	N/A
5. Enter user role interface policy view.	interface policy deny	By default, the interface policies of user roles permit access to all interfaces. This command disables the access of the user role to any interface.
6. (Optional.) Specify a list of interfaces accessible to the user role.	permit interface interface-list	By default, no accessible interfaces are configured. To add more accessible interfaces, repeat this step.

Changing the VLAN policy of a user role

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter user role view.	role name role-name	N/A
3. Enter user role VLAN policy view.	vlan policy deny	By default, the VLAN policies of user roles permit access to all VLANs. This command disables the access of the user role to any VLAN.
4. (Optional.) Specify a list of VLANs accessible to the user role.	permit vlan vlan-id-list	By default, no accessible VLANs are configured. To add more accessible VLANs, repeat this step.

Changing the VPN instance policy of a user role

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter user role view.	role name role-name	N/A
3. Enter user role VPN instance policy view.	vpn-instance policy deny	By default, the VPN policies of user roles permit access to all VPNs. This command disables the access of the user role to any VPN.
4. (Optional.) Specify a list of VPNs accessible to the user role.	permit vpn-instance vpn-instance-name&<1-10>	By default, no accessible VPNs are configured. To add more accessible VPNs, repeat this step.

Assigning user roles

To control user access to the system, you must assign at least one user role. Make sure at least one user role among the user roles assigned by the server exists on the device. User role assignment procedure varies with remote AAA authentication users, local AAA authentication users, and non-AAA authentication users (see "Assigning user roles").

Assigning user roles to remote AAA authentication users

A remote AAA authentication user must have at least one user role to log in to the device.

User roles are configured on the RADIUS server. For information about configuring user roles for a RADIUS user, see the RADIUS server documentation.

You can configure the default user role function to enable a remote AAA authentication user that has not been assigned any user role to log in with a default user role.

· For login to the default MDC, the default user role is network-operator.

· For login to a non-default MDC, the default user role is mdc-operator.

For more information about AAA authentication, see Security Configuration Guide.

To enable the default user role function for remote AAA authentication users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the default user role function.	role default-role enable	The default user role function is disabled.

Assigning user roles to local AAA authentication users

Configure user roles for local AAA authentication users in their local user accounts. Every local user has a default user role. If this default user role is not suitable, delete it. Because a local user must have at least one user role, the last user role cannot be deleted.

To assign a user role to a local user:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a local user and enter local user view.	local-user user-name class { manage \| network }	N/A
3. Authorize the user to have a user role.	authorization-attribute user-role role-name	Repeat this step to assign the user to up to 64 user roles. By default, network-operator is assigned to local users created by a network-admin user, and mdc-operator is assigned to the local users created by an mdc-admin or level-15 user.
4. Exit to system view.	quit	N/A
5. (Optional.) Enable the default user role function.	role default-role enable	Use this step if you configure non-AAA authorization for the local AAA user. The default user role function is disabled. Local AAA users that do not have a user role cannot log in to the device.

Assigning user roles to non-AAA authentication users on user interfaces

Specify user roles for the following two types of login users on the user interfaces:

· Users that use password authentication or no authentication.

· SSH clients that use publickey or password-publickey authentication. User roles assigned to these SSH clients are specified in their respective local management user accounts.

For more information about user interfaces, see "Login overview" and "Logging in to the CLI." For more information about SSH, see Security Configuration Guide.

To assign a user role to non-AAA authentication users on a user interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter user interface view.	user-interface { first-num1 [ last-num1 ] \| { aux \| console \| vty } first-num2 [ last-num2 ] }	N/A
3. Specify a user role on the user interface.	user-role role-name	Repeat this step to specify up to 64 user roles on a user interface. By default: · Network-admin is specified on the console user interface for default-MDC login users, and network-operator is specified on any other user interface for default-MDC login users. · After a default-MDC login user uses the switchto mdc command to log in to a non-default MDC, its user role changes from network-admin to mdc-admin. · The user role assigned to a non-default MDC login user is mdc-operator.

Configuring user role switching

You can switch to a different user role without reconnecting to the device. This operation does not change the user role settings in the user account that you have been logged in with, and it is effective only for the current login. The next time you are logged in with the user account, the original user role settings take effect.

Configuration guidelines

· A console user can switch the user role without authentication.

· To enable AUX or VTY users to switch the user role, you must configure user role switching authentication. Table 2 Authentication modes for user role switching describes the available authentication modes and configuration requirements.

· Local password authentication is available for switching to any user role, but remote AAA authentication is available only for switching to a level-n user role.

¡ If HWTACACS authentication is used, use a user account that has the target user role level or a user role level higher than the target user role for role switching. For example, if the user account test has the user role level-3, you can use this user account to switch the user role among level-0, level-1, level-2, and level-3. In this approach, you must enter the correct username and password to pass authentication.

¡ If RADIUS authentication is used, you must create a user account for each level-n user role in the $enabn$ format or the $enabn@domain-name$ format, where n represents the user role level. In this approach, the username you enter is ignored. You can pass authentication as long as the password is correct.

· If you execute the quit command after switching to a user role, you are logged out of the current user interface.

Table 2 Authentication modes for user role switching

Keywords	Authentication mode	Description
local	Local password authentication only (local-only)	The device uses the locally configured switching password for authentication.
scheme	Remote AAA authentication through HWTACACS or RADIUS (remote-only)	The device sends the username and password to the HWTACACS or RADIUS server for remote authentication. To use this mode, you must perform the following configuration tasks: · Configure the required HWTACACS or RADIUS scheme and configure the ISP domain to use the scheme for the user. For more information, see Security Configuration Guide. · Add the user account and password on the HWTACACS or RADIUS server.
local scheme	Local password authentication first and then remote AAA authentication (local-then-remote)	Local password authentication is performed first. If no switching password is configured, the device performs AAA authentication.
scheme local	Remote AAA authentication first and then local password authentication (remote-then-local)	AAA authentication is performed first. If the remote HWTACACS or RADIUS server does not respond or the AAA configuration on the device is invalid, local password authentication is performed.

Configuring user role switching authentication

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set an authentication mode.	super authentication-mode { local \| scheme } *	By default, local-only authentication applies.
3. Set a local authentication password for switching to a user role.	super password [ role rolename ] { hash \| simple } password	Use this step for local password authentication. By default, no switching password is configured. If you do not specify the role rolename option, the command sets the password for network-admin or mdc-admin. A default MDC user can use this password to switch to the network-admin, and a non-default MDC user can use this password to switch to the mdc-admin user role.

Switching the user role

An AUX or VTY user must pass authentication before switching to a user role.

Perform the following task in user view:

Task	Command	Remarks
Switch the user role.	super [ rolename]	The user role switching fails after three consecutive unsuccessful password attempts.

Displaying RBAC settings

Execute display commands in any view.

Task	Command
Display user role information.	display role [ name role-name ]
Display user role feature information.	display role feature [ name feature-name \| verbose ]
Display user role feature group information.	display role feature-group [ name feature-group-name ] [ verbose ]

RBAC configuration example for local AAA authentication users

Network requirements

The switch in Figure 1 performs local AAA authentication for the Telnet user at 192.168.1.58. This Telnet user has the username user1@bbb and is assigned the user role role1.

Configure role1 to have the following permissions:

· Executes the read commands of any feature.

· Configures no VLANs except VLANs 10 to 20.

Figure 1 Network diagram

Configuration procedure

# Assign an IP address to VLAN interface 2, the interface connected to the Telnet user.

<Switch> system-view

[Switch] interface vlan-interface 2

[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0

[Switch-Vlan-interface2] quit

# Enable Telnet server.

[Switch] telnet server enable

# Enable scheme authentication on the user interfaces for Telnet users.

[Switch] user-interface vty 0 15

[Switch-ui-vty0-15] authentication-mode scheme

[Switch-ui-vty0-15] quit

# Enable local authentication and authorization for the ISP domain bbb.

[Switch] domain bbb

[Switch-isp-bbb] authentication login local

[Switch-isp-bbb] authorization login local

[Switch-isp-bbb] quit

# Create the user role role1.

[Switch] role name role1

# Configure rule 1 to permit the user role to access read commands of all features.

[Switch-role-role1] rule 1 permit read feature

# Configure rule 2 to permit the user role to create VLANs and access commands in VLAN view.

[Switch-role-role1] rule 2 permit command system-view ; vlan *

# Change the VLAN policy to permit the user role to configure only VLANs 10 to 20.

[Switch-role-role1] vlan policy deny

[Switch-role-role1-vlanpolicy] permit vlan 10 to 20

[Switch-role-role1-vlanpolicy] quit

[Switch-role-role1] quit

# Create a management local user named user1 and enter its view.

[Switch] local-user user1 class manage

# Set a plaintext password aabbcc for the user.

[Switch-luser-manage-user1] password simple aabbcc

# Set the service type to Telnet.

[Switch-luser-manage-user1] service-type telnet

# Assign role1 to the user.

[Switch-luser-manage-user1] authorization-attribute user-role role1

# To make sure that the user has only the permissions of role1, remove the user from the default user role network-operator.

[Switch-luser-manage-user1] undo authorization-attribute user-role network-operator

[Switch-luser-manage-user1] quit

Verifying the configuration

# Telnet to the switch, and enter the username and password to access the user interface. (Details not shown.)

# Verify that you can create VLANs 10 to 20. This example uses VLAN 10.

<Switch> system-view

[Switch] vlan 10

[Switch-vlan10] quit

# Verify that you cannot create any VLANs other than VLANs 10 to 20. This example uses VLAN 30.

[Switch] vlan 30

Permission denied.

# Verify that you can use all read commands of any feature.

[Switch] display ?

acl Specify ACL configuration information

adjacent-table Display adjacent information

alarm Display alarm information

archive Display archive information

arp ARP module

bfd BFD module

bgp Border Gateway Protocol(BGP)

boot-loader Display boot-loader

---- More ----

# Verify that you cannot use the write or execute commands of any feature.

<Switch> debugging role all

Permission denied.

<Switch> ping 192.168.1.58

Permission denied.

RBAC configuration example for RADIUS authentication users

Network requirements

The switch in Figure 2 uses the FreeRADIUS server at 10.1.1.1/24 to provide AAA service for login users, including the Telnet user at 192.168.1.58. This Telnet user uses the username hello@bbb and is assigned the user role role2.

This user role has the following permissions:

· Performs all the commands in ISP view.

· Performs read and write commands of the features arp and radius.

· Has no access to read commands of the feature acl.

· Configures VLANs 1 to 20 and interfaces GigabitEthernet 3/0/1 to GigabitEthernet 3/0/24.

The switch and the FreeRADIUS server use the shared key expert and authentication port 1812. The switch delivers usernames with their domain names to the server.

Figure 2 Network diagram

Configuration procedure

Make sure that the settings on the switch and the RADIUS server match.

1. Configure the switch:

# Assign VLAN interface 2 an IP address from the same subnet as the Telnet user.

<Switch> system-view

[Switch] interface vlan-interface 2

[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0

[Switch-Vlan-interface2] quit

# Assign VLAN interface 3 an IP address from the same subnet as the RADIUS server.

[Switch] interface vlan-interface 3

[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0

[Switch-Vlan-interface3] quit

# Enable Telnet server.

[Switch] telnet server enable

# Enable scheme authentication on the user interfaces for Telnet users.

[Switch] user-interface vty 0 15

[Switch-ui-vty0-15] authentication-mode scheme

[Switch-ui-vty0-15] quit

# Create the RADIUS scheme rad and enter its view.

[Switch] radius scheme rad

# Specify the primary server address 10.1.1.1 and the service port 1812 in the scheme.

[Switch-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key to expert in the scheme for the switch to authenticate to the server.

[Switch-radius-rad] key authentication simple expert

[Switch-radius-rad] quit

# Specify the scheme rad as the authentication and authorization schemes for the ISP domain bbb.

IMPORTANT:

The authorization scheme must be the same as the authentication scheme to ensure successful authorization, because RADIUS does not separate authorization from authentication and sends authorization attributes in authentication responses.

[Switch] domain bbb

[Switch-isp-bbb] authentication login radius-scheme rad

[Switch-isp-bbb] authorization login radius-scheme rad

[Switch-isp-bbb] quit

# Create the feature group fgroup1.

[Switch] role feature-group name fgroup1

# Add the features arp and radius to the feature group.

[Switch-featuregrp-fgroup1] feature arp

[Switch-featuregrp-fgroup1] feature radius

[Switch-featuregrp-fgroup1] quit

# Create the user role role2.

[Switch] role name role2

# Configure rule 1 to permit the user role to use all commands available in ISP view.

[Switch-role-role2] rule 1 permit command system-view ; domain *

# Configure rule 2 to permit the user role to use read and write commands of all features in fgroup1.

[Switch-role-role2] rule 2 permit read write feature-group fgroup1

# Configure rule 3 to disable access to the read commands of the acl feature.

[Switch-role-role2] rule 3 deny read feature acl

# Configure rule 4 to permit the user role to create VLANs and use all commands available in VLAN view.

[Switch-role-role2] rule 4 permit command system-view ; vlan *

# Configure rule 5 to permit the user role to enter interface view and use all commands available in interface view.

[Switch-role-role2] rule 5 permit command system-view ; interface *

# Configure the user role VLAN policy to disable configuration of any VLAN except VLANs 1 to 20.

[Switch-role-role2] vlan policy deny

[Switch-role-role2-vlanpolicy] permit vlan 1 to 20

[Switch-role-role2-vlanpolicy] quit

# Configure the user role interface policy to disable configuration of any interface except GigabitEthernet 3/0/1 to GigabitEthernet 3/0/24.

[Switch-role-role2] interface policy deny

[Switch-role-role2-ifpolicy] permit interface GigabitEthernet 3/0/1 to GigabitEthernet 3/0/24

[Switch-role-role2-ifpolicy] quit

[Switch-role-role2] quit

2. Configure the RADIUS server:

# Add either of the user role attributes to the dictionary file of the FreeRADIUS server.

Cisco-AVPair = "shell:roles=\"role2\""

Cisco-AVPair = "shell:roles*\"role2\""

# Configure the settings required for the FreeRADIUS server to communicate with the switch. (Details not shown.)

Verifying the configuration

# Telnet to the switch, and enter the username and password to access the user interface. (Details not shown.)

# Verify that you can use all commands available in ISP view.

<Switch> system-view

[Switch] domain abc

[Switch-isp-abc] authentication login radius-scheme abc

[Switch-isp-abc] quit

# Verify that you can use all read and write commands of the features radius and arp. Take radius as an example.

[Switch] radius scheme rad

[Switch-radius-rad] primary authentication 2.2.2.2

[Switch-radius-rad] quit

# Verify that you cannot configure any VLAN except VLANs 1 to 20. Take VLAN 10 and VLAN 30 as examples.

[Switch] vlan 10

[Switch-vlan10] quit

[Switch] vlan 30

Permission denied.

# Verify that you cannot configure any interface except GigabitEthernet 3/0/1 to GigabitEthernet 3/0/24. Take GigabitEthernet 3/0/2 and GigabitEthernet 3/0/25 as examples.

[Switch] vlan 10

[Switch-vlan10] port GigabitEthernet 3/0/2

[Switch-vlan10] port GigabitEthernet 3/0/25

Permission denied.

RBAC configuration example for HWTACACS authentication users

Network requirements

The switch in Figure 3 uses local authentication for login users, including the Telnet user at 192.168.1.58. This Telnet user uses the username test@bbb and is assigned the user role level-0.

Configure the remote-then-local authentication mode for user role switching. The switch uses the HWTACACS server to provide authentication for user role switching among level-0 and level-3. If the AAA configuration is invalid or the HWTACACS server does not respond, the switch performs local authentication.

Figure 3 Network diagram

Configuration procedure

1. Configure the switch:

# Assign an IP address to VLAN-interface 2, the interface connected to the Telnet user.

<Switch> system-view

[Switch] interface vlan-interface 2

[Switch-Vlan-interface2] ip address 192.168.1.70 255.255.255.0

[Switch-Vlan-interface2] quit

# Assign an IP address to VLAN-interface 3, the interface connected to the HWTACACS server.

[Switch] interface vlan-interface 3

[Switch-Vlan-interface3] ip address 10.1.1.2 255.255.255.0

[Switch-Vlan-interface3] quit

# Enable Telnet server.

[Switch] telnet server enable

# Enable scheme authentication on the user interfaces for Telnet users.

[Switch] user-interface vty 0 15

[Switch-ui-vty0-15] authentication-mode scheme

[Switch-ui-vty0-15] quit

# Enable remote-then-local authentication for user role switching.

[Switch] super authentication-mode scheme local

# Create the HWTACACS scheme hwtac and enter its view.

[Switch] hwtacacs scheme hwtac

# Specify the primary authentication server address 10.1.1.1 and the service port 49 in the scheme.

[Switch-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Set the shared key to expert in the scheme for the switch to authenticate to the server.

[Switch-hwtacacs-hwtac] key authentication simple expert

# Exclude the ISP domain name from the username sent to the HWTACACS server.

[Switch-hwtacacs-hwtac] user-name-format without-domain

[Switch-hwtacacs-hwtac] quit

# Create ISP domain bbb and enter its view.

[Switch] domain bbb

# Configure ISP domain bbb to use local authentication for login users.

[Switch-isp-bbb] authentication login local

# Apply the HWTACACS scheme hwtac to the ISP domain.

[Switch-isp-bbb] authentication super hwtacacs-scheme hwtac

[Switch-isp-bbb] quit

# Create a management local user named test and enter its view. Set the service type to Telnet, and set the password to aabbcc.

[Switch] local-user test class manage

[Switch-luser-manage-test] service-type telnet

[Switch-luser-manage-test] password simple aabbcc

# Assign level-0 to the user.

[Switch-luser-test] authorization-attribute user-role level-0

[Switch-luser-test] quit

# Set the switching password to 654321 for the user role level-3.

[Switch] super password role level-3 simple 654321

[Switch] quit

2. Configure the HWTACACS server:

This example uses ACSv4.0.

a. Add a user account test.

b. Access the Advanced TACACS+ Settings page.

c. Select Level 3 for the Max Privilege for any AAA Client option.

d. Select the Use separate password option, and specify enabpass as the password.

Figure 4 Configuring advanced TACACS+ settings

Verifying the configuration

1. Telnet to the switch, and enter the username test@bbb and password aabbcc to access the user interface. Verify that you have access to diagnostic commands.

<Switch> telnet 192.168.1.70

Trying 192.168.1.70 ...

Press CTRL+K to abort

Connected to 192.168.1.59 ...

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

Password:

<Switch>?

User view commands:

display Display current system information

ping Ping function

quit Exit from current command view

ssh2 Establish a secure shell client connection

super Switch to a user role

system-view Enter the System View

telnet Establish a telnet connection

tracert Tracert function

2. Switch the user role:

# Use the super password to switch the user role. When the system prompts for a username and password, enter the username test@bbb and password enabpass.

<Switch> super level-3

Username: test@bbb

Password:

The following output shows that you have switched the user role to level-3.

User privilege role is level-3, and only those commands that authorized to the role can be used.

# If the ACS server does not respond, enter the local authentication password 654321 at the prompt.

Invalid configuration or no response from the authentication server.

Change authentication mode to local.

Password:

User privilege role is level-3, and only those commands that authorized to the role can be used.

The output shows that you have switched the user role to level-3.

Troubleshooting RBAC

This section describes several typical RBAC problems and their solutions.

Local users have more access permissions than intended

Symptom

A local user can use more commands than should be permitted by the assigned user roles.

Analysis

The local user might have been assigned user roles without your knowledge. For example, the local user is automatically assigned a default user role when you create it.

Solution

Use the display local-user command to examine the local user accounts for undesirable user roles, and delete them.

Login attempts by RADIUS users always fail

Symptom

Attempts by a RADIUS user to log in to the network access device always fail, even though the network access device and the RADIUS server can communicate with one another and all AAA settings are correct.

Analysis

RBAC requires that a login user have at least one user role. If the RADIUS server does not authorize the login user to use any user role, the user cannot log in to the device.

Solution

Resolve the problem in one of the following ways:

· Configure the role default-role enable command so a RADIUS user can log in with the default user role when no user role is assigned by the RADIUS server.

· Add the user role authorization attributes on the RADIUS server.

01-Fundamentals Configuration Guide

Configuring RBAC

Predefined user roles

Configuration task list

Creating user roles

RBAC configuration example for local AAA authentication users

RBAC configuration example for HWTACACS authentication users

Troubleshooting RBAC

Local users have more access permissions than intended

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us