Securing access

The SR Linux device is able to secure access to the device for users connecting via SSH or the console port, as well as for applications and FTP access. Authentication can be performed for users configured within the underlying Linux OS, and for administrative users configured within the SR Linux device itself.

Depending on the user type, users are authenticated locally on the device or through interaction with the SR Linux aaa_mgr application and an authentication server group (for example, TACACS+ or RADIUS).

User types

The SR Linux supports three user types: Linux users, local users, and remote users. Each user type is authenticated differently, as described in the following sections.

Linux users

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+ server group, a RADIUS server group, or password security for local users.

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

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.

AAA functions

The SR Linux performs authentication, authorization, and accounting (AAA) functions for each user type, as described in the following sections.

Authentication

For Linux users, 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.

SR Linux supports two encryption options: argon2 (ar2) and SHA512 (sha2). All local users who authenticate using plain text or hashed passwords, including the admin user, are subject to these encryptions. By default, the argon2 (ar2) encryption is used for clear-text passwords. See Password hashing for local users.

The sha2 encryption is the only available option for the linuxadmin user password. This user will not use the defined password hash-method.

Password security for local users

SR Linux supports password security features that apply to local users who authenticate using plain text or hashed passwords. The settings are system-wide configurations that apply to all locally configured users including the admin user, but excluding the linuxadmin user. The following password security features are supported:

  • password complexity rules

    Specifies rules that define the password requirements, including minimum and maximum length, minimum lowercase and uppercase characters, minimum numeric and special characters, and whether the password can include the user's full username or only the first three characters. The configuration of password complexity rules applies only to new passwords entered as clear text, not to pre-existing or pre-hashed ones.

  • password aging

    Specifies the number of days after which a password expires.

    Note:
    • Users with aged out passwords are prompted to update their password at the next login to the CLI. (This prompt only appears on the CLI.)
    • SR Linux does not provide advanced warning to users that their password is about to expire.
    • Aged out passwords expire indefinitely. They are not controlled by the lockout policy described below.

  • password change on first login

    Specifies whether local users must change their password on first login. The new password must match the defined password complexity rules.

  • password history

    Specifies the number of previous user passwords SR Linux retains to prevent reuse of old passwords.

  • lockout policy

    Specifies how many times a user can attempt a failed login within a defined period before they are locked out (for example: three attempts within 1 minute). The policy also defines whether the user is locked out indefinitely or only for a specified length of time.

Password hashing for local users

Password hashing is applied to all locally configured users, including the admin user, but excluding the linuxadmin user.

SR Linux supports argon2 (ar2) and SHA512 (sha2) algorithms for password encryption. You can choose to configure to use either the ar2 or the sha2 hash method.

The plain text user passwords are encrypted using the default hashing method ar2. When entering a hashed password value, the system verifies whether the entered password is encrypted using one of the supported algorithms. If the password has not been hashed using any of the supported algorithms, the system fails to commit the changes.

When you change the password, the system encrypts the password as per the configured hash method. See Configuring hash-method for local user passwords. Default is argon2 (ar2).

Authorization

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, and 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 Vendor-Specific Attributes (VSAs) 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.

Accounting

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.

AAA server group configuration

The SR Linux supports the following server group types for AAA functions:

  • local – uses local authentication, including /etc/passwd, /etc/group, and logging via syslog

  • TACACS+ – performs AAA via interaction with servers in a TACACS+ server group

  • RADIUS – performs AAA via interaction with servers in a RADIUS server group

The AAA type that is configured is used for all AAA functions and cannot use different types for different functions. Users whose AAA functions are handled by the aaa_mgr application (that is, the SR Linux admin user and local users) can use one of these server groups for authentication and accounting.

Each TACACS+ or RADIUS server group can have up to five servers. When authenticating a user or writing an accounting record, the SR Linux tries each server in the group in a round-robin fashion until a response is received. If no response is received within a specified timeout period, the SR Linux tries the next server in the group.

If no response is received from any of the servers in the group, the SR Linux moves to the next specified authentication or accounting method. If no other authentication method is specified, or the server group is the last method in the list, then the authentication or accounting request is rejected.

Configuring an AAA server group

You can configure authentication server groups for AAA functions. Configuring server groups provides a way to group the AAA server hosts. Grouping server hosts allows you to select a subset of the configured server hosts and use them for an AAA service. TACACS+ and RADIUS requests are sourced from the mgmt network-instance.

Configure TACACS+ and local server groups for AAA functions

Each server group consists of three servers. The timeout period specifies that the SR Linux wait 30 seconds for a response from a server before trying the next server in the group.

For the server group of type local, no external servers can be specified. The local server group uses /etc/passwd and /etc/group for authentication, and syslog for accounting. The timeout period specifies that the SR Linux wait a maximum of 60 seconds for an AAA function to complete.

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            server-group TACACS-GROUP {
                type tacacs
                timeout 30
                server 10.0.0.1 {
                    network-instance mgmt
                    tacacs {
                        secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                    }
                }
                server 10.0.0.2 {
                    network-instance mgmt
                    tacacs {
                        secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                    }
                }
                server 10.0.0.3 {
                    network-instance mgmt
                    tacacs {
                        secret-key $aes$3/Iz5veTDRV0=$6GxkrGjFbqWbYMA0T3itgQ==
                    }
                }
            }
            server-group LOCAL-GROUP {
                type local
                timeout 60
            }
        }
    }

Configure RADIUS server group for AAA functions

Each server group consists of three servers. The timeout period specifies that the SR Linux wait 30 seconds for a response from a server before trying the next server in the group. The server host entries are tried in the order in which they are configured. By default, the RADIUS protocol uses port 1812 for authentication and authorization, and port 1813 for accounting.
--{ * candidate shared default }--[  ]--
info system aaa
    system {
        aaa {
            server-group RADIUS-GROUP {
                type radius
                timeout 30
                server 10.0.0.1 {
                    network-instance mgmt
                    radius {
                        auth-port 1812
                        acct-port 1813
                        secret-key $aes$8PmWm6sNq6rk=$NJYoteWOP0/eiC+cixcGIA==
                    }
                }
                server 10.0.0.2 {
                    network-instance mgmt
                    radius {
                        auth-port 1812
                        acct-port 1813
                        secret-key $aes$3sAQYrLnXel4=$fNDL4gCDq+093xbiu8Bu5w==
                    }
                }
                server 10.0.0.3 {
                    network-instance mgmt
                    radius {
                        auth-port 1812
                        acct-port 1813
                        secret-key $aes$3OZ8ryLowRy4=$WrhWqCA3mvTXvAvb7sve1Q==
                    }
                }
            }
            server-group LOCAL-GROUP {
                type local
                timeout 60
            }
        }
    }

Authentication for the linuxadmin user

The SR Linux linuxadmin user is installed by default in /etc/passwd. The linuxadmin user has access to sudo to root and can run the SR Linux CLI with admin permissions.

The default password for the linuxadmin user is NokiaSrl1!. You can change this password via the SR Linux CLI or any other supported interface.

Configuring the password for the linuxadmin user

You can set a password for the linuxadmin user.

Note:

The SHA512 (sha2) encryption is the only available option for the linuxadmin user password.

--{ * candidate shared default }--[  ]--
# system aaa authentication linuxadmin-user password NewPass1234

When the user configuration is displayed, the password is hashed; for example:

--{ * candidate shared default }--[  ]--
# info system aaa authentication linuxadmin-user
    system {
        aaa {
            authentication {
                linuxadmin-user {
                    password $6$d091a49828c4cc87$CGe7QbxzZm/WadeMYF
                }
            }
        }
    }

Authentication for local users

Local users are those configured in the SR Linux CLI. For a local user, you can configure a password and specify one or more authentication methods, including local authentication or remote authentication using a TACACS+ or RADIUS server.

Note:

For authentication functionality such as password lockout and the failed-login-attempts counter, the NTP server must be enabled and in synchronization.

Configuring authentication for local users

By default, there is a single local user configured on the SR Linux, admin. The default password for the admin user is NokiaSrl1!. You can configure additional local users.

Note:

When you change the password, the system encrypts the password as per the configured hash method. See Configuring hash-method for local user passwords. Default is argon2 (ar2).

Configure a password for the SR Linux admin user

--{ * candidate shared default }--[  ]--
# system aaa authentication admin-user password NewPass1234

Configure a password for a local user srlinux

--{ * candidate shared default }--[  ]--
# system aaa authentication user srlinux password sr1l234

When the user configuration is displayed, the password is hashed ; for example:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                user srlinux {
                    password $ar2$KGSITqfJu5g=$iZZ6XKXtXOZOGMbeXO2ypg==
                }
            }
        }
    }

Change an existing user's password

To change an existing user’s password, use the same command that created the user and configure the new password; for example:

--{ * candidate shared default }--[  ]--
# system aaa authentication user srlinux password NewPasswordl234

Authentication methods

The following example specifies authentication methods. When a user attempts to log in, the user is authenticated using local authentication first. If local authentication fails, the SR Linux tries the servers in TACACS+ server group TACACS-GROUP.

If the user cannot be authenticated through any of these methods, the authentication attempt is rejected.

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                authentication-method [
                    LOCAL-GROUP
                    TACACS-GROUP
                ]
            }
        }
    }

Configuring password security for local users

All local users who authenticate using plain text or hashed value passwords, including the admin user, are subject to password security and user lockout settings.

To configure password security and user lockout features, set the following parameters under system aaa authentication:

  • password aging <0 to 500>

    Sets the number of days after which the user password expires and the user is prompted to update their password. The default of 0 sets the password to never expire.

  • password change-on-first-login [true | false]

    When set to true, forces local users to change their password on the first login to the system. The default is false.

  • password history <0 to 20>

    Specifies how many previous passwords SR Linux matches a new password against, such that the new password cannot be one of the previous <0 to 20> passwords. The default is 0, which disables password history.

  • password complexity-rules

    Sets the complexity rules that new passwords must match, using the following options:

    • minimum-length <1 to 12>

      Sets the minimum password length. The default is 1, which applies no minimum.

    • maximum-length <1 to 1023>

      Sets the maximum password length. The default is 1, which applies no maximum.

    • minimum-lowercase <0 to 10>

      Sets the minimum required lowercase characters. The default is 0, which applies no minimum.

    • minimum-uppercase <0 to 10>

      Sets the minimum required uppercase characters. The default is 0, which applies no minimum.

    • minimum-numeric <0 to 10>

      Sets the minimum required numeric characters. The default is 0, which applies no minimum.

    • minimum-special-character <0 to 10>

      Sets the minimum required number of special characters, which can include the following: (!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~"). The default is 0, which applies no minimum.

      Note: Users must enter the double quote as \" and the backslash as \\.
    • allow-user-name [true | false]

      Specifies whether the user can include their username as part of their password. If set to false, then SR Linux allows only the first three consecutive characters of the username in the user password. The default is true, which allows the password to contain the full username.

  • password lockout-policy

    Specifies the user lockout policy using the following parameters:

    • attempts <0 to 64>

      Sets the number of failed login attempts that trigger the lockout. The default is 0, which allows unlimited failed login attempts.

    • time <0 to 1440>

      Sets the time period in minutes within which the failed login attempts must occur to trigger the lockout. The timer starts at the first failure. The default is 1 minute.

    • lockout <0 to 1440>

      Sets the time period in minutes during which the user account remains locked out. A value of 0 means that the user account is locked out indefinitely. The default is 15 minutes.

  • require-ntp-sync [true | false]

    When set to false, this option forces the NTP synchronization check to be ignored and use only the system clock. The default is true. You can configure this setting in circumstances where the configured NTP servers are unreachable or unreliable. The configurable setting to ignore the NTP sync status is included in the password change-on-first-login (.system.aaa.authentication.password.change-on-first-login), password aging (.system.aaa.authentication.password.aging), and lockout policy mechanism (.system.aaa.authentication.password.lockout-policy).

    When included in the above features, the command require-ntp-sync disables NTP synchronization check. However, this command does not prevent the operator from syncing the system clock to NTP. It simply removes the dependency on NTP synchronization for those features.

Configure password security and user lockout

The following example sets the following password security and user lockout settings:
  • User passwords expire after 365 days.
  • Users must change their password on first login.
  • Users cannot reuse any of their 10 previous passwords.
  • Forces the NTP synchronization check to be ignored and use only the system clock.
  • Passwords must contain:
    • a minimum of eight and a maximum of 16 characters
    • one each of lowercase, uppercase, numeric, and special characters
  • Usernames are not allowed in the passwords.
  • After five failed attempts within 2 minutes, users are locked out indefinitely.
--{ * candidate shared default }--[ ]--
# info aaa authentication password
    aaa {
        authentication {
            password {
                aging 365
                change-on-first-login true
                history 10
                require-ntp-sync false
                complexity-rules {
                    minimum-length 8
                    maximum-length 16
                    minimum-lowercase 1
                    minimum-uppercase 1
                    minimum-numeric 1
                    minimum-special-character 1
                    allow-username false
                }
                lockout-policy {
                    attempts 5
                    time 2
                    lockout 0
                }
            }
        }
    }

Configuring hash-method for local user passwords

For local-user and admin-user passwords, you can choose the password hashing method by setting the hash-method parameter under .system.aaa.authentication.password.

By default, the hash-method is set to ar2.

Configuring the ar2 hashing algorithm 

--{ * candidate shared default }--[ ]--
# info system aaa authentication password hash-method
    system {
        aaa {
            authentication {
                password {
                    hash-method ar2
                }
            }
        }
    }

Configuring the sha2 hashing algorithm

--{ * candidate shared default }--[ ]--
# info system aaa authentication password hash-method
    system {
        aaa {
            authentication {
                password {
                    hash-method sha2
                }
            }
        }
    }

Clearing locked-out local users

To display locked out users, use the info from state system aaa authentication command, which displays a lockout state of active true when a user is locked out.

To clear a local user's lockout state, use the following tools command:

tools system aaa authentication user <username> unlock

Display user lockout state

--{ * candidate shared default }--[ ]--
#info from state system aaa authentication  
    system {
        aaa {
            authentication {
                exit-on-reject false
                idle-timeout 600
                authentication-method [
                    local
                ]
                user srl-test-1 {
                    password $bt$Vbf0Zgg8MGP=$ihHklTQHi/+3VwVD04Z8gh==
                    failed-login-attempts 10
                    last-failed-login 2022-07-29T22:35:23.801Z
                    password-change-required true
                    role [
                        test
                    ]
                    lockout {
                        active true
                        start 2022-07-29T22:35:23.801Z
                        end "14 minutes from now"
                    }
                }
                user srl-test-2 {
                    password $bt2$jBZBL6WAuTr=$eXYWpivE5z10YxBIZ06hjQ==
                    password-change-required true
                    role [
                        test
                    ]
                }

Clear user lockout state

--{ * candidate shared default }--[ ]--
#tools system aaa authentication user srl-test-1 unlock
/system/aaa/authentication/user[username=srl-test-1]:
    Unlocked user srl-test-1

Authorization using role-based access control

Authorization via role based access control is performed 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. Users can be configured with a set of one or more roles that define the privileges for which they are authorized in the system.

A role consists of one or more rules, which specify a schema path the role can have privileges for, and a corresponding action, which can be read, write, or deny. After authentication, a user is authorized to perform the specified action defined in the path for the role the user is assigned.

Role-based access control supports service and CLI plug-in authorization.
  • Service authorization allows you to limit the actions a user is authorized to perform to specific access types such as CLI and gNMI.

  • 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 or from the user's home directory. 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.

Role configuration

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 forward slash ‟/” 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 configuration is equivalent to a rule with the forward slash "/" 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 the forward slash ‟/” 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 must 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 .

Configuring a role

To configure a role, you define one or more rules that specify a path indicating the command string that is subject to authorization and a corresponding action such as read, write, or deny.

Configure a role with multiple rules

The following is an example of creating a role named testrole that contains two rules: one rule to limit access to network-instance red and another rule to give write access to the rest of the tree. A user assigned this role on authentication is able to configure everything in the system except network-instance red.

First, define the role under the system aaa authorization context:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authorization {
                role testrole {
                }
            }
        }
    }

Then specify the rules under the system configuration role context:

--{ * candidate shared default }--[  ]--
# info system configuration
    system {
        configuration {
            role testrole {
                rule / {
                    action write
                }
                rule "network-instance red" {
                    action read
                }
            }
        }
    }
Configure a role with view-only access permission

The following example configures a role named acl_app that allows a user to view the state of the acl_mgr application, but no other information:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authorization {
                role acl_app {
                }
            }
        }
    }

--{ * candidate shared default }--[  ]--
# info system configuration
    system {
        configuration {
            role acl_app {
                rule system {
                    action deny
                }
                rule "system app-management application acl_mgr state" {
                    action read
                }
            }
        }
    }

When a user that is assigned the acl_app role attempts to read information from the system state datastore, only the state of the acl_mgr application is displayed. For example:

--{ * candidate shared default }--[  ]--
# info from state system application acl_mgr
system {
    app-management {
        application acl_mgr {
            state running
        }
    }
}

Assigning roles to users

You can assign a user one or more roles. The rules configured in the user's role specify the commands the user is authorized to issue.

Up to 32 roles can be assigned to a user. If a user has multiple roles assigned, all of the rules configured in all of the roles apply to the user. If multiple roles reference the same path, the most specific rule is used.

For service authorization, the system merges all roles that have the service (CLI, gNMI, and so on) the user has logged in with and excludes any roles that omit the service.

When it comes to CLI plug-in authorization, any user who has the necessary role to load the plug-in can do so. The system follows an additive and permissive approach.

In the following example, the default local user admin and user testuser are assigned the role testrole.

After the testuser user is authenticated, the user is authorized to use the system according to the rules configured in the role testrole. Using the example from Configuring a role, this assignment authorizes the testuser user to configure everything in the system except for the network-instance red.

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                idle-timeout 7200
                authentication-method [
                    local
                ]
                admin-user {
                    role [
                        testrole
                    ]
                }
                linuxadmin-user {
                    password $6$skWKUdwWyM/$muyCaWpqJyaxYrs0J6nzb8tiM63W1HGKnsSOrb4JA7PiexF1q89PdualYQtyfl/q1qJJ9qyVE0CeTF0Csu87a/
                }
                user testuser {
                    role [
                        testrole
                    ]
                }
            }
        }
    }

Authorization using a TACACS+ server

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 are configured which map to a priv-lvl value.

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

Configuring TACACS+ Authorization

To configure TACACS+ authorization for SR Linux users, you enable priv-lvl authorization for the TACACS+ server group and configure roles that specify the priv-lvl mapping for each role subject to authorization using a TACACS+ server.

Enable priv-lvl authorization for a TACACS+ server group

The following configuration enables priv-lvl authorization for the TACACS-GROUP server group:

--{ * candidate shared default }--[  ]--
# info system aaa server-group TACACS-GROUP
    system {
        aaa {
            server-group TACACS-GROUP {
                priv-lvl-authorization true
            }
        }
    }
Configure roles with read access

The following configuration specifies two roles: interface oper-state and network-instance oper-state. The interface oper-state role grants read access for all interface oper-states, and the network-instance oper-state role grants read access for all network-instance oper-states. 

--{ * candidate shared default }--[  ]--
# info system configuration role *
    system {
        configuration {
            role "interface oper-state" {
                rule "interface * oper-state" {
                    action read
                }
            }
            role "network-instance oper-state" {
                rule "network-instance * oper-state" {
                    action read
                }
            }
        }
Enable priv-lvl mapping for the configured roles

The following configuration specifies the priv-lvl mapping for both roles.

In this example, when a user is authenticated, the SR Linux sends an authorization-request based on a shell (exec) session starting. The TACACS+ server returns an authorization-reply that specifies the priv-lvl value for the shell.

If the priv-lvl value returned by the TACACS+ server is 14, the user is assigned both roles; that is, read access to all interface oper-states and all network-instance oper-states, but no access to anything else in the system.

If the priv-lvl value returned by the TACACS+ server is 13, the user is assigned only the network-instance oper-state role and can read the oper-state for network-instances, but has no access to anything else in the system.

--{ * candidate shared default }--[  ]--
# info system aaa authorization
    system {
        aaa {
            authorization {
                role "interface oper-state" {
                    tacacs {
                        priv-lvl 14
                    }
                }
                role "network-instance oper-state" {
                    tacacs {
                        priv-lvl 13
                    }
                }
            }
        }
    }
Configure service authorization for a role

The following example configures service authorization for a role that uses TACACS+ authorization. See Configuring service authorization.

In this example, when a user is authenticated by a TACACS+ server in the server group TACACS-GROUP, if the TACACS server returns priv-lvl 15 for the user, then role_1 is assigned to the user.

Service authorization is configured for the role so that all services except gNMI are authorized for users assigned this role. This means users assigned role_1 are authorized for the functionality defined in the rules of role_1 if they connect using the CLI, JSON-RPC, or FTP, but are not authenticated if they connect using gNMI.

--{ * candidate shared default }--[  ]--
# info system aaa authorization role role_1
    system {
        aaa {
            authorization {
                role role_1 {
                    services [
                        cli
                        json-rpc
                        ftp
                    ]
                    tacacs {
                        priv-lvl 15
                    }
                }
            }
        }
    }

When 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, if a user is assigned role_1, which allows access to the system via CLI, and also assigned role_2, which allows access via gNMI, the user is authorized to use the CLI to perform the functions defined in the rules of role_1, and is authorized to use the gNMI interface for the functions defined in the rules of role_2.

Authorization using a RADIUS 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 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 supports the following VSAs:
  • Timetra-Profile <string>

    This VSA is mapped to the authorization roles which must be configured on the router.

  • Timetra-Cmd <string>

    This VSA configures a command or command subtree as the scope for the match condition. The command and all commands in subtrees are authorized

The supported VSAs are included in the RADIUS dictionary file dictionary-freeradius.txt in the support directory of the SR Linux software distribution.

The Nokia-defined attributes are encapsulated in a RADIUS vendor-specific attribute with the vendor ID field set to 6527, the vendor ID number.

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 only for the user session. These profiles are considered temporary configurations and are not saved when the user session terminates.

  3. Users authenticated with RADIUS and a user profile use RADIUS authorization, and not local authorization. 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.

Configuring RADIUS Authorization

To configure RADIUS authorization for SR Linux users, you enable authorization for the RADIUS server group and configure the UDP port number. By default, the RADIUS protocol uses port 1812 for authentication and authorization.

The following example configures services authorization for a role that uses RADIUS authorization.

--{ * candidate shared default }--[  ]--
info system aaa
    system {
        aaa {
            authorization {
                role role_1 {
                    services [
                        cli
                        gnmi
                        ftp
                    ]
                }
            }
        }
    }

Service authorization

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 only via the gNMI interface.

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.

Configuring service authorization

To configure service authorization, you create a role that defines rules permitting or denying access to system functionality, assign the role to one or more users, and specify the services over which users assigned the role are authorized to perform the rules defined in the role.

Create a role

The following example creates a role read-oper-state that allows reading subinterface oper-state but nothing else:

--{ * candidate shared default }--[  ]--
# info system configuration role *
    system {
        configuration {
            role read-oper-state {
                rule / {
                    action deny
                }
                rule "interface * subinterface * oper-state" {
                    action read
                }
            }
        }
    }
Assign the role to a user

The following example assigns read-oper-state role to the default local user admin. Additionally, it creates a user gnmiuser that is assigned the read-oper-state role when authenticated. 

--{ * candidate shared default }--[  ]--
# info system aaa authentication
    system {
        aaa {
            authentication {
                authentication-method [
                    local
                ]
                admin-user {
                    role [
                        read-oper-state
                    ]
                }
                user gnmiuser {
                    role [
                        read-oper-state
                    ]
                }
            }
        }
    }
Configure service authorization for the role

The following example configures service authorization so that users assigned the read-oper-state role, such as admin/gnmiuser, can perform the functionality defined in the role only if they have connected to the system via gNMI. If the user connects via a different service, such as by logging into the CLI, the user is not authorized for the functionality defined in the role.

--{ * candidate shared default }--[  ]--
# info system aaa authorization
    system {
        aaa {
            authorization {
                role read-oper-state {
                    services [
                        gnmi
                    ]
                }
            }
        }
    }

CLI plug-in authorization for local users

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.

To configure the CLI plug-in authorization, set the following parameters under system aaa authorization role:
  • allow-command-list

    Specify the list of CLI commands allowed to execute.

  • deny-command-list

    Specify the list of CLI commands not allowed to execute.

  • load-global-plugins [true | false]

    Specifies whether CLI should load plug-ins from global plug-in directory ( /etc/opt/srlinux/cli/plugins/). If set to false, no plug-ins are loaded from the global plug-in directory. The default is true, which allows plug-ins to be loaded from the global plug-in directory.

  • load-user-plugins [true | false]

    Specifies whether CLI should load plug-ins from user's home directory ( ~/cli/plugins/). If set to false, no plug-ins are loaded from the user's home directory. The default is true, which allows plug-ins to be loaded from the user's home directory.

Configuring CLI plug-in authorization

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.

Configure CLI plug-in authorization for the role

The following example configures CLI authorization so that users assigned to the loadglobal-plugins role, such as cliuser, can load only the global plug-ins and execute only the info and tools command without having access to the bash commands.

--{ * candidate shared default }--[  ]--
# info system aaa authorization role loadglobal-plugins cli
    system {
        aaa {
            authorization {
                role loadglobal-plugins {
                    cli {
                        load-global-plugins true
                        load-user-plugins false
                        deny-command-list [
                            bash
                        ]
                        allow-command-list [
                            info
                            tools
                        ]
                    }
                }
            }
        }
    }
--{ * candidate shared default }--[  ]--
# info system aaa authentication user cliuser
    system {
        aaa {
            authentication {
                user cliuser {
                    role [
                        loadglobal-plugins
                    ]
                }
            }
        }
    }

Accounting configuration

When accounting is enabled, the SR Linux device generates command accounting records as described in Accounting.

The following is an example of accounting records generated by the SR Linux device:

Aug 7 22:34:09
127.0.0.1 bob ssh 172.17.0.1 start task_id=2 timezone=UTC service=shell priv-lvl=15 
cmd=tail -f /var/log/tac_plus.acct
Aug 7 22:34:09
127.0.0.1 bob ssh 172.17.0.1 stop task_id=2 timezone=UTC service=shell priv-lvl=15 
cmd=tail -f /var/log/tac_plus.acct
Aug 7 22:34:14
127.0.0.1 bob ssh 172.17.0.1 start task_id=5 timezone=UTC service=shell priv-lvl=15 
cmd=help
Aug 7 22:34:14
127.0.0.1 bob ssh 172.17.0.1 stop task_id=5 timezone=UTC service=shell priv-lvl=15 
cmd=help
The following is an example of accounting records from the FreeRADIUS server:
Wed Feb 15 08:13:05 2023
        Acct-Status-Type = Start
        NAS-IP-Address = 0.0.0.0
        User-Name = "user151"
        Acct-Session-Id = "0000332023-02-15T07:12:54.772Z"
        Calling-Station-Id = "172.18.0.1"
        NAS-Port-Type = Virtual
        Timetra-Cmd = "show system aaa authentication session 33"
        Event-Timestamp = "Feb 15 2023 08:13:05 CET"
        Timestamp = 1676445185

Wed Feb 15 08:13:05 2023
        Acct-Status-Type = Stop
        NAS-IP-Address = 0.0.0.0
        User-Name = "user151"
        Acct-Session-Id = "0000332023-02-15T07:12:54.772Z"
        Calling-Station-Id = "172.18.0.1"
        NAS-Port-Type = Virtual
        Timetra-Cmd = "show system aaa authentication session 33"
        Event-Timestamp = "Feb 15 2023 08:13:05 CET"
        Timestamp = 1676445185

Configuring TACACS+ accounting

To configure TACACS+ accounting for SR Linux users, enable accounting for the TACACS+ server group.

The SR Linux generates an accounting record when a command is started and when it is stopped.

The following example configures accounting records to be sent to the TACACS-GROUP server group.
--{ * candidate shared default }--[  ]--
# info system aaa
system {
    aaa {
        accounting {
            accounting-method [
                TACACS-GROUP
            ]
            event commands {
                record start-stop
            }
        }
    }
}

Configuring RADIUS accounting

To configure RADIUS accounting for SR Linux users, enable accounting for the RADIUS server group and configure the accounting port.

The SR Linux generates an accounting record when a command is started and when it is stopped. The accounting records are sent to the RADIUS server using UDP packets on port 1813.

The following example configures the RADIUS server group for accounting.

--{ * candidate shared default }--[  ]--
# info system aaa
 system {
     aaa {
         accounting {
            accounting-method [
                RADIUS-GROUP
            ]
            event commands {
                record start-stop
            }
         }
     }
 }

Displaying user session information

To display information about users currently logged into the SR Linux device, use the show system aaa authentication session command.

# show system aaa authentication session
+----+----------+---------+--------------+-------+-----+------------+----------+
| ID |   User   | Service | Authentica   | Priv- | TTY |  Remote    | Login    |
|    |   name   |   name  |   cation     |  lvl  |     |   host     | time     |
|    |          |         |   method     |       |     |            |          |
+====+==========+=========+==============+=======+=====+============+==========+
| 30 | admin    | sshd    | LOCAL-GROUP  |       | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:04 |
|    |          |         |              |       |     |            | :04.040Z |
| 31 | bob      | sshd    | TACACS-GROUP |  15   | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:05 |
|    |          |         |              |       |     |            | :36.854Z |
| 32 | user151* | sshd    | RADIUS-GROUP |       | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:05 |
|    |          |         |              |       |     |            | :36.854Z |
+----+----------+---------+--------------+-------+-----+------------+----------+

Disconnecting user sessions

To disconnect a user currently logged in to the SR Linux device, use the tools system disconnect session-id <session-id> command and specify the session ID of the user. To list the session IDs of active users, enter the show system aaa authentication session command.

# show system aaa authentication session
+----+----------+---------+--------------+-------+-----+------------+----------+
| ID |   User   | Service | Authentica   | Priv- | TTY |  Remote    | Login    |
|    |   name   |   name  |   cation     |  lvl  |     |   host     | time     |
|    |          |         |   method     |       |     |            |          |
+====+==========+=========+==============+=======+=====+============+==========+
| 30 | admin    | sshd    | LOCAL-GROUP  |       | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:04 |
|    |          |         |              |       |     |            | :04.040Z |
| 31 | bob      | sshd    | TACACS-GROUP |  15   | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:05 |
|    |          |         |              |       |     |            | :36.854Z |
| 32 | user151* | sshd    | RADIUS-GROUP |       | ssh | 172.18.0.1 | 2023-11- |
|    |          |         |              |       |     |            | 02T04:05 |
|    |          |         |              |       |     |            | :36.854Z |
+----+----------+---------+--------------+-------+-----+------------+----------+

# tools system disconnect session-id 31
Terminating cli session 31 owned by user 'bob' logged from ssh
/system/aaa/authentication/session[id=31]:
Disconnecting aaa cli session(s): 31

Configuring the idle-timeout period for user sessions

You can configure the idle-timeout period for user sessions, which disconnects a user session after a specified period of inactivity. By default, user sessions are disconnected after 15 minutes of inactivity.

The idle-timeout period setting applies to SR Linux users and remote users. It does not apply to Linux users or to JSON-RPC or gNMI client sessions.

When a user session is inactive for one-half of the idle-timeout period, a notification is displayed indicating that the user will be logged out if the session remains idle for the remainder of the idle-timeout period.

The following example configures the idle-timeout period so that SR Linux user sessions and remote user sessions are disconnected after 20 minutes of inactivity:

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                idle-timeout 20
            }
        }
    }