Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

class (Defining Login Classes)

Syntax

Hierarchy Level

Description

Define a login class. All users who log in to the router or switch must be in a login class. Therefore, you must define a Junos OS login class for each user or type of user. You can define any number of login classes depending on the types of permissions the users need. You may not need to define any login classes; Junos OS has several predefined login classes, to suit a variety of needs. However, the predefined login classes cannot be modified. If you define a class with the same name as a predefined class, Junos OS appends -local to the login class name and creates a new login class. See Predefined System Login Classes for more information.

Options

class-name

A name you choose for the login class.

access-end

Specify the end time in HH:MM (24-hour) format, where HH represents the hours and MM represents the minutes.

Note:

Access start and end times that span across 12:00 AM starting on a specified day results in the user having access until the next day, even if the access day is not explicitly configured on the allowed-days statement.

access-start

Specify the start time in HH:MM (24-hour) format, where HH represents the hours and MM represents the minutes.

Note:

Access start and end times that span across 12:00 AM starting on a specified day results in the user having access until the next day, even if the access day is not explicitly configured on the allowed-days statement.

( allow-commands | allow-commands-regexps )

Specify one or more regular expressions to allow users in this class to issue operational mode commands. You use the allow-commands or the allow-commands-regexps statement to explicitly allow authorization for commands that would otherwise be denied by the access privilege levels for a login class.

For the allow-commands statement, each expression separated by a pipe (|) symbol must be a complete standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular expressions separated with parentheses and connected with the pipe (|) symbol.

For the allow-commands-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator. Each string is evaluated against the full path of the command, which provides faster matching than the allow-command statement. You can also include values for variables in the regular expressions, which is not supported using the allow-commands statement.

The deny-commands or the deny-commands-regexps statement takes precedence if it is used in the same login class definition.

Note:

The allow/deny-commands and allow/deny-commands-regexps statements are mutually exclusive and cannot be configured together for a login class. At a given point in time, a login class can include either the allow/deny-commands statements, or the allow/deny-commands-regexps statements. If you have existing configurations using the allow/deny-commands statements, using the same configuration options with the allow/deny-commands-regexps statements might not produce the same results, as the search and match methods differ in the two forms of these statements.

Authorizations can also be configured remotely by specifying Juniper Networks vendor-specific TACACS+ attributes in your authentication server's configuration. For a remote user, when the authorization parameters are configured both remotely and locally, authorization parameters configured remotely and locally are both considered together for authorization. For a local user, only the authorization parameters configured locally for the class are considered.

  • Default: If you do not configure authorizations for operational mode commands using the allow/deny-commands or allow/deny-commands-regexps statements, users can edit only those commands for which they have access privileges set with the permissions statement.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

( allow-configuration | allow-configuration-regexps )

Specify one or more regular expressions to explicitly allow users in this class to access the specified levels in the configuration hierarchy even if the permissions set with the permissions statement do not grant such access.

For theallow-configuration statement, each expression separated by a pipe (|) symbol must be a complete standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular expressions separated with parentheses and connected with the pipe (|) symbol.

For the allow-configuration-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator. Each string is evaluated against the full path of the command, which provides faster matching than the allow/deny-configuration statements. You can also include values for variables in the regular expressions, which is not supported using the allow/deny-configuration statements.

The deny-configuration or deny-configuration-regexps statement takes precedence if it is used in the same login class definition.

Note:

The allow/deny-configuration and allow/deny-configuration-regexps statements are mutually exclusive and cannot be configured together for a login class. At a given point in time, a login class can include either the allow/deny-configuration statements, or the allow/deny-configuration-regexps statements. If you have existing configurations using the allow/deny-configuration statements, using the same configuration options with the allow/deny-configuration-regexps statements might not produce the same results, as the search and match methods differ in the two forms of these statements.

  • Default: If you omit the allow-configuration/allow-configuration-regexps statement and the deny-configuration/deny-configuration-regexps statement, users can edit only those commands for which they have access privileges through the permissions statement.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

allow-configuration-exact-match

This option uses complete hierarchy strings and wildcards in addition to regular expressions. Specify a hierarchy including set, delete, active, or deactive to explicitly allow users in this class to access the specified configuration.

The allow-configuration-exact-match option offers more granular control over access privileges than the allow-configuration option. For example if you use allow-configuration-exact-match set interfaces <*> to allow a login class access to the set interfaces configuration, it will not grant access to the delete interfaces configuration.

If you set the same configuration for both allow-configuration-exact-match and deny-configuration-exact-match, then the then the configuration access will be denied.

allow-grpc-rpc-regexps

Specify one or more regular expressions to explicitly allow users in this class to execute matching GRPC RPCs

For the allow-grpc-rpc-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator.

The deny-grpc-rpc-regexps statement takes precedence if it is used along with allow-grpc-rpc-regexps in the same login class definition.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

allow-hidden-commands

Allow all hidden commands to be run. If the no-hidden-commands statement is specified at the [edit system] hierarchy level, overrides that restriction for this login class. Hidden commands are Junos OS commands that are not published but could be run on a router. Hidden commands serve a specific purpose, but for most part are not expected to be used, and as such are not actively supported. The no-hidden-commands statement at the [edit system] hierarchy level allows you to block all hidden commands to all users except the root users.

  • Default: Hidden commands are enabled by default.

allowed-days [ days of the week ]

Specify one or more days of the week when users in this class are allowed to log in.

  • Values:

    • monday—Monday

    • tuesday—Tuesday

    • wednesday—Wednesday

    • thursday—Thursday

    • friday—Friday

    • saturday—Saturday

    • sunday—Sunday

cli

Set the CLI prompt specified for the login class. If a CLI prompt is also set at the [edit system login user cli] hierarchy level, the prompt set for the login user has precedence over the prompt set for the login class.

prompt prompt

Specify the prompt string you want to see displayed in the CLI prompt.

configuration-breadcrumbs

Enable the configuration breadcrumbs view in the CLI to display the location in the configuration hierarchy. For an example of how to enable this view, see Enabling Configuration Breadcrumbs .

confirm-commands

Specify that confirmation for particular commands is explicitly required and, optionally, specify the wording of the message displayed at confirm time. You can specify the commands using a list of regular expressions or commands.

  • Syntax: message

  • Default: If you omit this option, then confirmation for commands is not required. If the optional message is not set, then the default "Do you want to continue?" message is displayed.

( deny-commands | deny-commands-regexps )

Specify one or more regular expressions to explicitly deny users in this class permission to issue operational mode commands, even though the permissions set with the permissions statement would allow it.

For the deny-commands statement, each expression separated by a pipe (|) symbol must be a complete standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular expressions separated with parentheses and connected with the pipe (|) symbol.

For the deny-commands-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator. Each string is evaluated against the full path of the command, which provides faster matching than the allow/deny-command statements. You can also include values for variables in the regular expressions, which is not supported using the allow/deny-commands statements.

Expressions configured with the deny-commands or the deny-commands-regexps statement take precedence over expressions configured with allow-commands/allow-commands-regexps if the two statements are used in the same login class definition.

Note:

The allow/deny-commands and allow/deny-commands-regexps statements are mutually exclusive and cannot be configured together for a login class. At a given point in time, a login class can include either the allow/deny-commands statements, or the allow/deny-commands-regexps statements. If you have existing configurations using the allow/deny-commands statements, using the same configuration options with the allow/deny-commands-regexps statements might not produce the same results, as the search and match methods differ in the two forms of these statements.

Authorizations can also be configured remotely by specifying Juniper Networks vendor-specific TACACS+ attributes in your authentication server's configuration. For a remote user, when the authorization parameters are configured both remotely and locally, authorization parameters configured remotely and locally are both considered together for authorization. For a local user, only the authorization parameters configured locally for the class are considered.

  • Default: If you do not configure authorizations for operational mode commands using allow/deny-commands or allow/deny-commands-regexps, users can edit only those commands for which they have access privileges set with the permissions statement.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

( deny-configuration | deny-configuration-regexps )

Specify one or more regular expressions to explicitly deny users in this class access to the specified levels in the configuration hierarchy even if the permissions set with the permissions statement grant such access. Note that the user cannot view a particular hierarchy if configuration access is denied for that hierarchy.

For the deny-configuration statement, each expression separated by a pipe (|) symbol must be a complete standalone expression, and must be enclosed in parentheses ( ). Do not use spaces between regular expressions separated with parentheses and connected with the pipe (|) symbol.

For the deny-configuration-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator. Each string is evaluated against the full path of the command, which provides faster matching than the allow/deny-configuration statements. You can also include values for variables in the regular expressions, which is not supported using the allow/deny-configuration statements.

Expressions configured with deny-configuration/deny-configuration-regexps take precedence over expressions configured with allow-configuration/allow-configuration-regexps if the two statements are used in the same login class definition.

Note:

The allow/deny-configuration and allow/deny-configuration-regexps statements are mutually exclusive and cannot be configured together for a login class. At a given point in time, a login class can include either the allow/deny-configuration statements, or the allow/deny-configuration-regexps statements. If you have existing configurations using the allow/deny-configuration statements, using the same configuration options with the allow/deny-configuration-regexps statements might not produce the same results, as the search and match methods differ in the two forms of these statements.

  • Default: If you omit the deny-configuration/deny-configuration-regexps statement and the allow-configuration/allow-configuration-regexps statement, users can edit those levels in the configuration hierarchy for which they have access privileges through the permissions statement.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

deny-configuration-exact-match

This option uses complete hierarchy strings and wildcards in addition to regular expressions. Specify a hierarchy including set, delete, active, or deactive to explicitly deny users in this class to access the specified configuration.

The deny-configuration-exact-match option offers more granular control over denying privileges than the deny-configuration option. For example if you use deny-configuration-exact-match set interfaces <*> to deny a login class access to the set interfaces configuration, it will not grant access to the set interfaces configuration.

If you set the same configuration for both allow-configuration-exact-match and deny-configuration-exact-match, then the then the configuration access will be denied.

Configurations that are denied with deny-configuration-exact-match will return a Permission denied error if configured. Denied configurations will still appear as autocomplete entries when using the Tab or Spacebar keys in the Junos CLI.

deny-grpc-rpc-regexps

Specify one or more regular expressions to prevent users in this class from running matching GRPC RPCs

For the deny-grpc-rpc-regexps statement, you configure a set of strings in which each string is a regular expression, enclosed in double quotes and separated with a space operator.

The deny-grpc-rpc-regexps statement takes precedence over the allow-grpc-rpc-regexps if it is used in the same login class definition.

  • Syntax: regular-expression—Extended (modern) regular expression as defined in POSIX 1003.2. If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Enter as many expressions as needed.

idle-timeout

For a login class, configure the maximum time in minutes that a session can be idle before the session times out and the user is logged out of the device. The session times out after remaining at the CLI operational mode prompt for the specified time.

Note:

After the user logs in to a device from a shell prompt such as csh, if the user starts another program to run in the foreground of the CLI, the idle-timer control is stopped from being computed. The calculation of the idle time of the CLI session is restarted only after the foreground process exits and the control is returned to the shell prompt. When the restart of the idle-timer control occurs, if no interaction from the user occurs on the shell, the user is automatically logged out after the time set on this statement.

  • Default: If you omit this statement, a user is never forced off the system after extended idle times.

  • Syntax: minutes—Maximum time in minutes that a session can be idle before a user is logged out.

  • Range: Range: 0 through 4294967295 minutes

    Note:

    The idle-timeout feature is disabled if the value of minutes is set to 0.

login-alarms

Display system alarms when a user with admin permissions logs in to the device. For more information about configuring this statement, see Configuring System Alarms to Appear Automatically Upon Login.

login-script

Run the specified op script when a user belonging to the class logs in to the CLI. The script must be enabled in the configuration.

logical-system

Assign the users in this login class to a logical system. If you specify a logical system, you can’t include the satellite configuration statement in the configuration for this login class.

login-tip

Display CLI tips when logging in.

  • Default: If this statement is not configured, CLI tips are not displayed.

no-hidden-commands

Deny all hidden commands, except for those specified, for users in this login class. Each command listed as an exception must be enclosed in quotation marks.

  • Default: Hidden commands are enabled by default.

  • Syntax: except [“command 1” “command 2”...]

no-scp-server

Disable incoming SCP connections for this login class.

no-sftp-server

Disable incoming SFTP connections for this login class.

permissions

Specify login access privileges for the login class.

  • Syntax: permissions—One or more permission flags, which together specify the access privileges for the login class. Permission flags are not cumulative, so for each class, you must list all the permission flags needed, including view to display information and configure to enter configuration mode. For a list of permission flags, see Login Class Permission Flags.

satellite

Specify access to Junos Fusion satellite devices for the login class. All users assigned to the login class are satellite users. If you include this statement, you can’t include the logical-system configuration statement in the configuration for this login class.

  • Values:

    • all—Specify all Junos Fusion satellite devices.

security-role

Specify one or more Common Criteria (ISO/IEC 15408) security roles for the login class.

  • Values:

    audit-administrator

    Specify which users are responsible for the regular review of specific target of evaluation (TOE) audit data and audit trail deletion. Audit administrators can also invoke the non-cryptographic self-test.

    crypto-administrator

    Specify which users are responsible for the configuration and maintenance of cryptographic elements related to the establishment of secure connections to and from the TOE audit data.

    ids-administrator

    Specify which users can act as intrusion detection service (IDS) administrators, who are responsible for all of the activities regarding identity and access management of the organization’s employees.

    security-administrator

    Specify which users are responsible for ensuring that the organization’s security policy is in place.

tenant

Assign the users in this class to a tenant system. Tenant systems are used when you need to separate departments, organizations, or customers and each of them can be limited to one virtual router. The main difference between a logical system and a tenant system is that a logical system supports advanced routing functionality using multiple routing instances. In comparison, a tenant system supports only one routing instance, but supports the deployment of significantly more tenants per system.

web-ui-hidden-menus

Enable hidden menus in the J-Web interface.

web-ui-read-only-menus

Enable read-only menus in the J-Web interface.

Required Privilege Level

admin—To view this statement in the configuration.

admin-control—To add this statement to the configuration.

Release Information

The class, allow-commands, deny-commands, allow-configuration, deny-configuration, idle-timeout, login-alarms, login-tip, and permissions statements were introduced before Junos OS Release 7.4.

All of the previously mentioned statements were introduced in Junos OS Release 9.0 for the EX Series.

The login-script statement was introduced in Junos OS Release 9.5.

The access-end, access-start, and allowed-days statements were introduced in Junos OS Release 10.1.

All of the previously mentioned statements were introduced in Junos OS Release 11.1 for the QFX Series.

All of the previously mentioned statements were introduced in Junos OS Release 11.2 for the SRX Series.

The allow-configuration-regexps, deny-configuration-regexps, and security-role statements were introduced in Junos OS Release 11.2.

The configuration-breadcrumbs statement was introduced in Junos OS Release 12.2.

All of the previously mentioned statements were introduced in Junos OS Release 14.1X53-D20 for the OCX Series.

All of the previously mentioned statements were introduced in Junos OS Release 15.1X49-D70 for the vSRX Virtual Firewall, SRX4100, SRX4200 and SRX1500 devices.

All of the previously mentioned statements were introduced in Junos OS Release 16.1 for the MX Series and PTX Series.

The allow-hidden-commands, confirm-commands, no-hidden-commands, and satellite statements were introduced in Junos OS Release 16.1.

The cli statement was introduced in Junos OS Release 17.3.

The allow-commands-regexps and deny-commands-regexps statements were introduced in Junos OS Release 18.1.

The tenant statement was introduced in Junos OS 18.4.

The no-scp-server and no-sftp-server statements were introduced in Junos OS Release 19.2.

The web-ui-hidden-menus and web-ui-read-only-menus statements were introduced in Junos OS 21.3 for the SRX platforms.