User Authentication
Module Introduction
Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:
student@tour:~/trainings_resources/robot$ robot user_auth/user_auth_setup.robotIntroduction
If you wish to manage your switch remotely, access to the device via a networking protocol such as HTTPS or SSH is essential. Accessing the switch, for example, via an SSH connection, necessitates user authentication. For security reasons, it is not recommended to share usernames and passwords among different users. Thus, we need to have multiple users, each with their password.
RBFS supports two methods for user authentication:
-
Creation of a local username and password on the switch itself.
-
Utilizing a centralized user database via TACACS+.
Local User Accounts
Local user accounts are defined directly on a device and can be assigned rights and permissions for that device only. The RBFS system comes with three predefined user accounts: supervisor, operator, and reader. Additional user accounts can be added using the set system user <username> command syntax.
New users created through local user management will always have a primary group with the same name and ID as the created user. The new user’s ID will be allocated within the range of 3000 and 3999.
|
You cannot use usernames such as |
User passwords can be configured as either plaintext passwords or hashed text. Once configured, the password is always displayed in the hashed form in the resulting configuration. If no password is configured, password authentication is disabled for this particular user.
|
You can disable password authentication for any predefined user, such as supervisor, by adding the user to the system users without any password. Additionally, you can upload an SSH public key for user authentication, which works even if no password authentication is configured. |
Each user needs to be assigned a shell. RBFS offers three valid options:
-
/usr/sbin/nologinpreventing access -
/bin/bashwhich allows access to the Linux system -
/usr/local/bin/cliwhich provides direct access to the RBFS CLI
Configure a local user bob with role supervisor and shell /usr/local/bin/cli. The password should be set to sesame123. Verify that you can access the system via ssh using this new user account.
Click to reveal the answer
cfg> set system user bob role supervisor
cfg> set system user bob display-name "Bob"
cfg> set system user bob shell /usr/local/bin/cli
cfg> set system user bob password-plain-text sesame123
cfg> commitOnce you have configured the local user account, you can verify it from your localhost:
$ ssh bob@R1
The authenticity of host 'R1 (127.0.1.1)' can't be established.
ED25519 key fingerprint is SHA256:rUWzdWKqVLEQxJ/8C4iSTTaQf+XC4L1WCefLXtDgx4M.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'R1' (ED25519) to the list of known hosts.
bob@r1's password:
Last login: Wed Dec 13 07:09:38 2023 from 10.0.3.1
bob@R1>lab.rtbrick.net: op>Note, that due to the shell configuration, the user directly enters the RBFS CLI.
User Roles
RBFS allows you to create privileges that are configurable for user-defined and pre-defined roles. RBFS supports a combination of permit and deny regular expressions and a configurable default privilege to support both blacklisting and whitelisting of users.
You can define a new role using the set system authorization global role <name> command hierarchy. The commands allow-cmds and deny-cmds allow you to precisely define which commands a user assigned to this role is allowed to execute.
|
If a command matches a regular expression that is defined in both |
Configure a new role called lookingglass and assign this role to the previously defined user bob. The lookingglass role should deny any commands other that ping, show bgp, show route, and exit. Verify that you can access the system via ssh using account bob and that show isis neighbor is not allowed, while show bgp peer works.
Click to reveal the answer
cfg> set system authorization global role lookingglass cmd-permission allow-cmds "ping .*"
cfg> set system authorization global role lookingglass cmd-permission allow-cmds "show bgp .*"
cfg> set system authorization global role lookingglass cmd-permission allow-cmds "show route .*"
cfg> set system authorization global role lookingglass cmd-permission allow-cmds "exit"
cfg> set system authorization global role lookingglass cmd-permission deny-cmds .*
cfg> delete system user bob role supervisor
cfg> set system user bob role lookingglass
cfg> commitLet’s check together if the configuration works:
$ ssh bob@R1
bob@r1's password:
Last login: Wed Dec 13 08:40:40 2023 from 127.0.0.1
bob@R1>lab.rtbrick.net: op> show isis neighbor
Instance: default
Interface System Level State Type Up since Expires
hostif-0/0/1/0 R2 L2 Up P2P Wed Nov 15 07:30:26 in 29s 358885us
hostif-0/0/2/0 R3 L2 Up P2P Wed Nov 15 07:30:23 in 29s 384864usThis is not what we have expected as show isis commands should be denied. The reason for this to happen is that you need to enable secure-management for roles to work.
|
You need to have secure management enabled ( |
Enable secure management on the system and verify that the show isis neighbor command is now forbidden.
Click to reveal the answer
cfg> set system secure-management-status true
cfg> commitNow let’s check again:
$ ssh bob@R1
bob@r1's password:
Last login: Wed Dec 13 08:41:17 2023 from 127.0.0.1
bob@R1>lab.rtbrick.net: op> show isis neighbor
CLI syntax error: "show isis neighbor": Unauthorized command execution user: bob
bob@R1>lab.rtbrick.net: op> show bgp peer
bob@R1>lab.rtbrick.net: op>The good news is that the show isis commands are now denied. However, although the show bgp commands seems to be allowed, it does not provide any information. The reason is that the user does not have permission to access the corresponding BDS tables and objects that the commands use internally. Thus we need to grant permission using the set system authorization global role <name> rbac-permission table|object comamnd syntax.
Enable read permissions for all tables and objects for the previously defined role lookingglass and verify that show bgp peer now works for user bob.
Click to reveal the answer
cfg> set system authorization global role lookingglass rbac-permission table ".*" permission -/read/-
cfg> set system authorization global role lookingglass rbac-permission object ".*" permission -/read/-
cfg> commitTACACS+
If the number of devices and users increases, local user management does not scale anymore. For this reason, a centralized user database storing user credentials and access privileges is used, simplifying user account administration and ensuring consistency across multiple network devices.
Terminal Access Controller Access Control System Plus (TACACS+) is a protocol that allows a switch to communicate with a central user database. With TACACS+ enabled, the RBFS system forwards authentication requests by remote users to the TACACS+ server. The TACACS+ server, which stores user account information, authenticates users.
|
The predecessor of TACACS+ was TACACS. While TACACS supported communication via UDP and TCP, TACACS+ only uses TCP. The main advantage of TACACS+ is that it encrypts all traffic between the switch and the server. |
When a user attempts to access RBFS, the device sends an authentication request to the TACACS+ server, which validates the user’s credentials (username and password). After successful authentication, the TACACS+ server sends an authorization response back to the network device, including information about the user’s privileges, specifying the actions or commands the user is allowed to perform on the device. TACACS+ also provides an additional layer of security as there are no user credentials stored locally on the switch, reducing the risk of unauthorized access if a device is compromised.
A user can log either into the RBFS container through inband management. i.e., via a network port, or into the underlying ONL through out-of-band management using the dedicated management port of the switch. The second option does not exist in virtual environments. The management-type needs to be configured when defining a TACACS+ server via set system authorization tacacs <server-ip>. For TACACS+ to work with inband management, inband configuration must be enabled using the command set inband-management instance <instance-name> tacacs true.
Configure a new interface to connect to the TACACS+ server. Create VLAN 10 on interface hostif-0/0/0 with IP address 172.16.101.1/28 and verify that the TACACS+ server is reachable. Define a TACACS+ server with IP address 172.16.101.2 and secret testing123. Enable the inband-manangement in instance default to use tacacs.
Verify that user alice can access the system using password sesame123. Also verify that alice is able to execute the command show version, but not the command show route.
Click to reveal the answer
cfg> delete interface hostif-0/0/0 admin-status down
cfg> set interface hostif-0/0/0 unit 10 instance default
cfg> set interface hostif-0/0/0 unit 10 vlan 10
cfg> set interface hostif-0/0/0 unit 10 address ipv4 172.16.101.1/28
cfg> set system authorization tacacs 172.16.101.2 inband secret-plain-text testing123
cfg> set inband-management instance default tacacs true
cfg> commitThere are different TACACS+ server available. For reference, we have listed the configuration of a TACACS+ server running on Ubuntu Linux which was used in this lab exercise:
accounting file = /var/log/tac_plus.acct
key = testing123
user = alice {
name = "Alice"
member = Network_Operator
login = cleartext "sesame123"
}
group = Network_Operator {
default service = permit
service = exec {
priv-lvl = 10
rtb-deny-cmds = "show bgp.*;show isis.*;show route.*"
}
}
priv-lvl is a mandatory attribute in the TACACS+ user configuration.
|