class (Defining Login Classes)

A name you choose for the login class.

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

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

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.

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.

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.

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

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.

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

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

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.

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 .

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

Display CLI tips when logging in.

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

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”...]

Disable incoming SCP connections for this login class.

Disable incoming SFTP connections for this login class.

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.

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.

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.

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.

Enable hidden menus in the J-Web interface.

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