Securing access

Linux users are those configured in the underlying Linux OS, not in the SR Linux configuration. Information about Linux users is stored in /etc/passwd in the underlying Linux OS.

By default, the SR Linux has a single Linux user, linuxadmin, who has access to sudo to root and can run the SR Linux CLI with administrative permissions. The default password for the linuxadmin user is NokiaSrl1!, which can be changed; see Configuring the password for the linuxadmin user. Nokia recommends that you change this default user and password as soon as possible. Other Linux users can be added with the useradd command in the underlying Linux OS.

Linux users with a UID less than 1500, are authenticated via the underlying Linux OS, not through the SR Linux aaa_mgr application. This means that Linux users are not subject to authentication settings configured within SR Linux, such as authentication by a TACACS+ or a RADIUS server group, or password security for local users.

Local users are users configured within the SR Linux itself. By default, SR Linux supports a single local user, named admin; other local users can be added as necessary.The default password for the admin user is NokiaSrl1!, which you can change using the SR Linux CLI; see Configuring authentication for local users. Nokia recommends that you change this default password as soon as possible.

Local users are authenticated via a gRPC interface to the aaa_mgr application. See Authentication for local users for an example configuration.

Remote users are users that are not configured either in /etc/passwd or within the SR Linux configuration. Remote users are configured on a remote server, which is queried when the user attempts to log in to the SR Linux device.

For Linux users, the SR Linux authenticates via the authentication mechanism built into the underlying Linux OS.

For local users, including the SR Linux admin user, the SR Linux uses its gRPC interface to the aaa_mgr application for authentication. Authentication settings that apply to the local users, including a local password and TACACS+ or RADIUS server group, can be configured . See Authentication for local users for information about configuring local users.

For remote users, authentication is performed using the aaa_mgr application in coordination with the remote system.

User passwords (those configured uding the .system.aaa.authentication.user{} list) use argon2 encryption, and the linuxadmin user uses SHA-512 encryption.

The SR Linux implements authorization through role-based access control, where each authenticated user is assigned one or more predefined roles that specify the functions the user is allowed to perform on the system. If no role is configured for a user, then the user is assigned a role that allows access to CLI plugins, but no other functions.

All user types, including the default local user admin, are authorized through role-based control on all interfaces (CLI, gNMI, JSON-RPC). However, the linuxadmin user is an exception and is granted write access to all commands in the command tree. Role-based access control supports service and CLI plug-in authorization. You can configure service authorization, which can limit the interface types for which the functions in a role are authorized. CLI plug-in authorization gives you control over how operator-provided plug-ins are loaded.

You can configure the SR Linux to use information from a TACACS+ or RADIUS server to assign roles to an authenticated user.

• In TACACS+ authorization, the priv-lvl value in the Authorization REPLY packet received from the TACACS+ server maps to a role configured on the SR Linux. The user is assigned the role that corresponds to the priv-lvl value.

• RADIUS combines authentication and authorization. The RADIUS server authorizes the user by applying a profile based on username and password configurations. The profiles are configured using VSAs (Vendor-Specific Attribute) on the RADIUS server. The actions an authenticated user can perform depend on the user profiles. Profiles consist of a suite of commands that the user is allowed or not allowed to execute.

See Authorization using role-based access control for information about configuring roles for users.

The SR Linux supports command accounting. Accounting records generated by the SR Linux include the entire CLI string that a user enters on the command line, including any pipes or output redirects specified in the command.

You can configure the SR Linux device to send accounting records to a destination specified in an accounting-method list, such as a TACACS+ or RADIUS server group or the local system.

For each user type, the SR Linux device generates accounting records as follows:

• For local users, including the SR Linux admin user, command accounting records are sent to the destination specified in the accounting-method list, both for commands entered in the SR Linux CLI and for commands entered in the bash shell.

• For Linux users and remote users, command accounting records are sent for commands entered in the SR Linux CLI (including Linux commands entered in the SR Linux CLI using the bash command), although not for commands entered in the bash shell.

See Configuring TACACS+ accounting and Configuring RADIUS accounting for an example configurations.

Roles consist of a set of rules that define a schema path-reference and a corresponding action. The path-reference specifies system functions that are subject to authorization, and the action specifies the privilege type for users assigned the role: read, write, or deny.

The path-reference is specified relative to the root level. For example, the path-reference ‟/” indicates all CLI functions at the root level and below; the path-reference ‟/system” indicates all CLI functions at the system level and below, and the path-reference ‟/system configuration” indicates all CLI functions at the system configuration level and below.

If no role is assigned to a user at login, the user has access to all CLI plugins, but no access to CLI commands at any level. This is equivalent to a rule with / as the path-reference and deny as the action.

When no roles are configured, the admin retains its superuser privileges. This ensures backward compatibility with previous releases that only allowed role configuration for all users except for the admin and linuxadmin users.

Up to 32 roles are supported; each role can have a list of up to 256 paths. The order of the path-references in a role does not matter; the longest match is used when validating a command against a path-reference.

The syntax for the path-reference is SR Linux CLI format, with ‟/” representing the root. Wildcards and ranges can be used with path-references, in the same way they can in CLI syntax.

Each entry within the path-reference should use double quotes, unless the command string is a single word with no spaces. If the path itself includes quotes, use backslash characters to indicate the quotes. For example, to specify the following in a path-reference:

a "b" and c "d"

You can configure the following for the path-reference:

path-reference "a \"b\"" "c \"d\""

The roles control the service and CLI plug-in authorization .

You can configure the SR Linux to use a TACACS+ server to provide authorization for role-based access control. When TACACS+ authorization is configured, the actions an authenticated user can perform depend on the priv-lvl value configured for the user on a TACACS+ server. If priv-lvl-authorization is not set to true, the authenticated user is authorized as an admin user.

TACACS+ authorization for SR Linux users works as follows:

1. After a user is authenticated, the SR Linux sends the TACACS+ server an authorization-request message based on a shell (exec) session starting. This authorization-request is sent immediately following user authentication, but before the shell is started.

2. The TACACS+ server returns an authorization-reply message that includes the priv-lvl value configured for the user for shell access.

3. On the SR Linux, roles have been configured that map to a priv-lvl value.

4. The SR Linux allows the user to perform actions specified in roles with a priv-lvl value equal or lower to the priv-lvl value returned by the TACACS+ server.

RADIUS combines authentication and authorization. The RADIUS server authorizes the user by applying a profile based on username and password configurations. The profiles are configured using VSAs (Vendor-Specific Attributes) on the RADIUS server. The actions an authenticated user can perform depend on the user profiles. Profiles consist of a suite of commands that the user is allowed or not allowed to execute.

SR Linux uses the vendor and other VSA information from Nokia SR OS.

RADIUS authorization for SR Linux users works as follows:

1. The SR Linux sends the username and password to the RADIUS server.

2. If the username and password are recognized, the RADIUS server returns the user authorization information (user profiles encoded into the VSA).

   If the username and password are not recognized, access is denied and passed on to the next configured authentication method. If no other authentication method is configured, or the RADIUS server group is the last method in the list, then the authentication/authorization request is rejected.

   Note: The user profiles downloaded from the RADIUS server are stored on the SR Linux for the user session only. These profiles are considered temporary configurations and are not saved when the user session terminates.

3. RADIUS authorization is used for users authenticated with RADIUS and a user profile, and local authorization is not used. When a user issues a command, SR Linux compares the command and the user information against the information present in the downloaded RADIUS user profile. The profile provides details about the command that the user is authorized and not authorized to execute. The user can execute only the authorized commands. If a user profile is not received, the user can execute all commands.

Service authorization allows you to block or allow access to a user depending on the interface they use to connect to the device. You can use service authorization to restrict access to a controller, allowing it to speak through programmatic interfaces, but without credentials that can be used by someone logged into the CLI.

You can configure the service and CLI plug-in authorization all user types including the default local user admin (admin), with the exception of the linuxadmin/root users, which are permitted write access to all commands in the command tree.

To configure service authorization, you assign roles to local users that authorize them to issue commands using specified services, such as the CLI, gNMI, or JSON-RPC interfaces. For example, you can define a role that grants read access to subinterface statistics, and limits access to that information to the gNMI service. When you assign that role to a user, the user is allowed to read subinterface information via the gNMI interface only.

The following interface types can be configured for service authorization:

• cli - access to the system via CLI
• gnmi - access to the system via gNMI
• json-rpc - access to the system via JSON-RPC
• ftp - access to the system via FTP
• p4rt - access to the system via P4Runtime RPCs

After a user is authenticated, the system checks whether the user is assigned a role that allows access via the interface they used to connect to the device. For example, if a user connects using gNMI, the system checks whether the user is assigned any roles that authorize access via the gNMI interface. If the user is assigned a role that authorizes access via gNMI, the user receives access to the system via gNMI according to the rules defined in the set of roles that includes gNMI. If the user connects via gNMI, but is not assigned any role that authorizes access via gNMI, the authorization attempt is rejected and the session is closed.

If a user is assigned multiple roles, the user is authorized for all services specified in the roles they are assigned, according to the rules defined in the roles. For example, consider a user assigned role r1, which allows access to the system via CLI, and also assigned role r2, which allows access via gNMI. The user is authorized to use the CLI to perform the functions defined in the rules of role r1, and is authorized to use the gNMI interface for the functions defined in the rules of role r2.

By default, a role has no services configured for authorization. When you configure a role, you must specify the services that apply to the role. Users assigned the role are authorized to perform the functions defined in the role using the specified services.

CLI plug-in authorization gives you control over how operator-provided plug-ins are loaded. You can choose to load them from the global plug-in directory (/etc/opt/srlinux/cli/plugins/) or from the user's home directory (~/cli/plugins/). This feature also allows you to control the execution of CLI plug-ins and the queries they make against the data model. Additionally, you can manage the list of CLI commands that are allowed or not allowed to execute.

You can configure the CLI plug-in authorization for all user types including the default local user admin (admin), with the exception of the linuxadmin/root users, which are permitted write access to all commands in the command tree.

To configure CLI plug-in authorization, you assign roles to users that authorize them to load plug-ins from either the global or user plug-ins directory. Additionally, you can specify the list of CLI commands that users assigned to the role are authorized to execute.

For example, you can define a role that grants permission to load plug-ins only from users home directory. When you assign this role to a user, the user can only load plug-ins from the home directory.

After a user is authenticated, the system checks whether the user is assigned a role that allows loading of plug-ins from the intended location and has permission to execute the intended CLI commands. If the authorization is successful, the user can perform the functionality as defined in the role. If the authorization fails, the user is denied access to the functionality defined in the role.