Securing access

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+ or 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, 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.

Password security for local users

SR Linux supports password security features that apply to local users who authenticate using plain text 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 will expire.
Note:
- Users with aged out passwords are prompted to update their password at the next login to the CLI. (This prompt appears on the CLI only.)
- 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.

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.

Authorization via role based access control is performed for all user types on all interfaces (CLI, gNMI, JSON-RPC), with the exception of the admin and linuxadmin users, which are permitted write access to all commands in the command tree. You can configure service authorization, which can limit the interface types for which the functions in a role are authorized.

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.

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 authentication, authorization, and accounting via interaction with servers in a TACACS+ server group.
RADIUS – Performs authentication, authorization, and accounting 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

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 a AAA service. TACACS+ and RADIUS requests are sourced from the mgmt network-instance.

The following example configures a 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
            }
        }
    }

The following example configures a 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

Use the following command to set the password for the linuxadmin user.

--{ * 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 within 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.

The following example configures a password for the SR Linux admin user:

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

The following example creates a local user called srlinux and configures a password:

--{ * 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==
                }
            }
        }
    }

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

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

Password security and user lockout settings apply to all local users who authenticate using plain text passwords including the admin user.

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 special characters: (!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~"). 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.

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.
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
                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
                }
            }
        }
    }

Clear local user lockout

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 is performed through role-based access control. Users can be configured with a set of one or more roles that indicate 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 authorization, which allows you to limit the actions a user is authorized to perform to specific access types such as CLI and gNMI.

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 ‟/” 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.

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\""

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.

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 upon 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
                }
            }
        }
    }

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

A user can be assigned one or more roles. The rules configured in the user's roles 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.

In the following example, the user srlinux is assigned the role testrole.

After the srlinux 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 would authorize the srlinux user to configure everything in the system except for the network-instance red.

--{ * candidate shared default }--[  ]--
# info system aaa
    system {
        aaa {
            authentication {
                user srlinux {
                    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:

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.
The TACACS+ server returns an authorization-reply message that includes the priv-lvl value configured for the user for shell access.
On the SR Linux, roles have been configured that map to a priv-lvl value.
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.

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.

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
            }
        }
    }

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
                }
            }
        }

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
                    }
                }
            }
        }
    }

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 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 (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 supports the following VSAs:

Timetra-Profile is mapped to the authorization roles.
Timetra-Cmd configures a command or command subtree as the scope for the match condition.

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

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

RADIUS authorization for SR Linux users works as follows:

The SR Linux sends the username and password to the RADIUS server.
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.
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.

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.

# info system aaa authorization role role_1
system {
        aaa {
            authorization {
                role role_1 {
                    services [
                        cli
                        ftp
                        gnmi
                    ]
                }
            }
        }
    }

Service authorization for local users

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.

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.

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.

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
                }
            }
        }
    }

The following example 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
                ]
                user gnmiuser {
                    role [
                        read-oper-state
                    ]
                }
            }
        }
    }

The following example configures service authorization so that users assigned the read-oper-state role, such as 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
                    ]
                }
            }
        }
    }

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

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

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 at port 1813.

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

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 in to the SR Linux device, use the show system aaa authentication session command.

# show system aaa authentication session
  +----+-----------+--------------+-----------------------+----------+-----+-------------+--------------------------+
  | ID | User name | Service name | Authentication method | Priv-lvl | TTY | Remote host |        Login time        |
  +====+===========+==============+=======================+==========+=====+=============+==========================+
  | 30 | admin     | sshd         | LOCAL-GROUP           |          | ssh | 172.18.0.1  | 2023-02-15T07:06:50.048Z |
  | 31 | bob       | sshd         | TACACS-GROUP          |    15    | ssh | 172.18.0.1  | 2023-12-15T07:07:15.087Z |
  | 32 | user151*  | sshd         | RADIUS-GROUP          |          | ssh | 172.18.0.1  | 2023-02-15T07:09:47.695Z |
  +----+-----------+--------------+-----------------------+----------+-----+-------------+--------------------------+

The asterisk (*) next to the username indicates the session from which the show system aaa authentication session was invoked.

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 name | Service name | Authentication method | Priv-lvl | TTY | Remote host |        Login time        |
  +====+===========+==============+=======================+==========+=====+=============+==========================+
  | 30 | admin     | sshd         | LOCAL-GROUP            |          | ssh | 172.18.0.1  | 2023-02-15T07:06:50.048Z |
  | 31 | bob       | sshd         | TACACS-GROUP           |    15    | ssh | 172.18.0.1  | 2023-12-15T07:07:15.087Z |
  | 32 | user151*  | sshd         | RADIUS-GROUP           |          | ssh | 172.18.0.1  | 2023-02-15T07:09:47.695Z |
  +----+-----------+--------------+-----------------------+----------+-----+-------------+--------------------------+ 

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

Configuring idle-timeout for user sessions

You can configure the idle-timeout 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 setting applies to SR Linux users and remote users. It does not apply to Linux users or to JSON-RPC or gNMI client sessions.

After a user session has been 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 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
            }
        }
    }