Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

User Access Privileges

You (the system administrator) grant users access or permissions to commands and configuration hierarchy levels and statements. Users can execute only those commands and view and configure only those statements for which they have access privileges. You can also use extended regular expressions to specify which operational mode commands, configuration statements, and hierarchies are allowed or denied for users. This practice prevents unauthorized users from executing sensitive commands or configuring statements that could cause damage to the network.

Access Privilege Levels Overview

Each top-level CLI command and configuration statement has an associated access privilege level. Users can execute only those commands and configure and view only those statements for which they have access privileges. One or more permission flags define the access privileges for each login class.

For each login class, you can also explicitly allow or deny the use of operational mode and configuration mode commands and statement hierarchies that would otherwise be allowed or denied by a privilege level specified in the permissions statement.

Login Class Permission Flags

You use permission flags to grant a user access to operational mode commands and configuration hierarchy levels and statements. You configure permission flags for the user's login class at the [edit system login class] hierarchy level. When you specify a certain permission flag, the user gains access to the commands and to the configuration hierarchy levels and statements that correspond to that flag. To grant access to all commands and configuration statements, use the all permissions flag.

Note:

Each command listed represents that command and all subcommands with that command as a prefix. Each configuration statement listed represents the top of the configuration hierarchy to which that flag grants access.

The permissions statement specifies one or more of the permission flags listed in Table 1. Permission flags are not cumulative. For each class you must list all the permission flags needed, including view to display information and configure to enter configuration mode. Two forms of permissions control a user's access to the individual parts of the configuration:

  • "Plain” form—Provides read-only capability for that permission type. An example is interface.

  • -control form—Provides read and write capability for that permission type. An example is interface-control.

For permission flags that grant access to configuration hierarchy levels and statements, the plain form flags grant read-only privilege to that configuration. For example, the interface permission flag grants read-only access to the [edit interfaces] hierarchy level. The -control form of the flag grants read-write access to that configuration. For example, the interface-control flag grants read-write access to the [edit interfaces] hierarchy level.

Table 1 lists the login class permission flags that you can configure by including the permissions statement at the [edit system login class class-name] hierarchy level.

The permission flags grant a specific set of access privileges. Each permission flag is listed with the operational mode or configuration mode commands and configuration hierarchy levels and statements for which that flag grants access.

Table 1: Login Class Permission Flags

Permission Flag

Description

access

Can view the access configuration in operational mode or configuration mode.

access-control

Can view and configure access information at the [edit access] hierarchy level.

admin

Can view user account information in operational mode or configuration mode.

admin-control

Can view user account information and configure it at the [edit system] hierarchy level.

all

Can access all operational mode commands and configuration mode commands. Can modify the configuration in all the configuration hierarchy levels.

clear

Can clear (delete) information that the device learns from the network and stores in various network databases (using the clear commands).

configure

Can enter configuration mode (using the configure command) and commit configurations (using the commit command).

control

Can perform all control-level operations—all operations configured with the -control permission flags.

field

Can view field debug commands. Reserved for debugging support.

firewall

Can view the firewall filter configuration in operational mode or configuration mode.

firewall-control

Can view and configure firewall filter information at the [edit firewall] hierarchy level.

floppy

Can read from and write to the removable media.

flow-tap

Can view the flow-tap configuration in operational mode or configuration mode.

flow-tap-control

Can view and configure flow-tap information at the [edit services flow-tap] hierarchy level.

flow-tap-operation

Can make flow-tap requests to the router or switch. For example, a Dynamic Tasking Control Protocol (DTCP) client must have flow-tap-operation permission to authenticate itself to Junos OS as an administrative user.

Note:

The flow-tap-operation option is not included in the all-control permissions flag.

idp-profiler-operation

Can view profiler data.

interface

Can view the interface configuration in operational mode and configuration mode.

interface-control

Can view chassis, class of service (CoS), groups, forwarding options, and interfaces configuration information. Can modify the configuration at the following hierarchy levels:

  • [edit chassis]

  • [edit class-of-service]

  • [edit groups]

  • [edit forwarding-options]

  • [edit interfaces]

maintenance

Can perform system maintenance, including starting a local shell on the device and becoming the superuser in the shell (using the su root command) and halting and rebooting the device (using the request system commands).

network

Can access the network by using the ping, ssh, telnet, and traceroute commands.

pgcp-session-mirroring

Can view the pgcp session mirroring configuration.

pgcp-session-mirroring-control

Can modify the pgcp session mirroring configuration.

reset

Can restart software processes by using the restart command.

rollback

Can use the rollback command to return to a previously committed configuration.

routing

Can view general routing, routing protocol, and routing policy configuration information in configuration mode and operational mode.

routing-control

Can view and configure general routing at the [edit routing-options] hierarchy level, routing protocols at the [edit protocols] hierarchy level, and routing policy information at the [edit policy-options] hierarchy level.

secret

Can view passwords and other authentication keys in the configuration.

secret-control

Can view and modify passwords and other authentication keys in the configuration.

security

Can view security configuration information in operational mode and configuration mode.

security-control

Can view and configure security information at the [edit security] hierarchy level.

shell

Can start a local shell on the router or switch by using the start shell command.

snmp

Can view Simple Network Management Protocol (SNMP) configuration information in operational mode or configuration mode.

snmp-control

Can view and modify SNMP configuration information at the [edit snmp] hierarchy level.

system

Can view system-level information in operational mode or configuration mode.

system-control

Can view and modify system-level configuration information at the [edit system] hierarchy level.

trace

Can view trace file settings and configure trace file properties.

trace-control

Can modify trace file settings and configure trace file properties.

view

Can use various commands to display current system-wide, routing table, and protocol-specific values and statistics. Cannot view the secret configuration.

view-configuration

Can view all of the configuration excluding secrets, system scripts, and event options.

Note:

Only users with the maintenance permission can view commit script, op script, or event script configuration.

Allow and Deny Individual Commands and Statement Hierarchies for Login Classes

By default, all top-level CLI commands and configuration hierarchy levels have associated access privilege levels. Users can execute only those commands and view and configure only those statements for which they have access privileges. For each login class, you can explicitly allow and deny the use of operational mode and configuration mode commands and statement hierarchies that would otherwise be allowed or denied by a privilege level specified in the permissions statement.

Permission flags grant a user access to operational mode and configuration mode commands and to configuration hierarchy levels and statements. By specifying a specific permission flag on the user's login class at the [edit system login class] hierarchy level, you grant the user access to the corresponding commands and configuration hierarchy levels and statements. To grant access to all commands and configuration statements, use the all permissions flag.

You can explicitly allow or deny the use of commands and statements by configuring the allow-commands, deny-commands, allow-configuration, and deny-configuration statements for a login class. In the statements, you use extended regular expressions to define which commands and statements to allow or deny for users assigned to the class.

Example: Configure User Permissions with Access Privilege Levels

This example configures the user permissions for a login class. You configure user permissions for a login class to prevent users from performing unauthorized network actions. Users can execute only those commands and view and modify only those statements for which they have access privileges. This constraint prevents unauthorized users from executing sensitive commands or configuring statements that could cause damage to the network.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

Each top-level CLI command and each configuration statement has an access privilege level associated with it. When you configure a login class, you can explicitly allow or deny the use of operational mode and configuration mode commands and configuration statements. Users can execute only those commands and view and configure only those statements for which they have access privileges.

You define the access privileges for each login class by specifying one or more permission flags in the permissions statement. Permission flags grant a user access to commands, statements, and hierarchies. Permission flags are not cumulative. For each login class you must list all the permission flags needed, including view to display information and configure to enter configuration mode. By specifying a specific permission flag on the user's login class, you grant the user access to the corresponding commands, statements, and hierarchies. To grant access to all commands and configuration statements, use the all permissions flag. The permission flags provide read-only (“plain” form) and read and write (form that ends in -control) capability for a permission type.

Note:

The all login class permission bits take precedence over extended regular expressions when a user issues a rollback command with the rollback permission flag enabled.

To configure user access privilege levels for a login class, include the permissions statement at the [edit system login class class-name] hierarchy level, followed by the permission flags. Configure multiple permissions as a space-separated list enclosed in square brackets:

Tip:

To view the available permissions, use the CLI's context-sensitive help and type a question mark (?) after the permissions statement:

Configuration

This example configures the snmp-admin login class. Users in this login class can configure and view SNMP parameters only.

Configure User Permissions with Access Privilege Levels

Step-by-Step Procedure

To configure access privileges for the login class:

  1. Configure the snmp-admin login class with the configure, snmp, and snmp-control permission flags.

    The configured permission flags provide both read (snmp) and read-and-write (snmp-control) capability for SNMP, and this is the only allowed access privilege for this login class. All other access privileges are denied.

  2. Create the user accounts that are assigned to the snmp-admin login class.

Results

In configuration mode, confirm your configuration by entering the show system login command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

After configuring the device, enter commit in configuration mode.

Verification

Log in using a username assigned to the new login class, and confirm that the configuration is working properly.

Verify SNMP Configuration

Purpose

Verify that a user in the snmp-admin login class can configure SNMP.

Action

In configuration mode, configure SNMP statements at the [edit snmp] hierarchy level.

Meaning

The user in the snmp-admin login class is able to configure SNMP parameters. The user can configure these parameters because the permission flags specified for this class include both snmp (read capabilities) and snmp-control (read and write capabilities) permission bits.

Verify non-SNMP Configuration

Purpose

Verify that a user in the snmp-admin login class cannot modify non-SNMP configuration statements.

Action

In configuration mode, attempt to configure any non-SNMP statement, such as a statement in the interfaces hierarchy.

Meaning

The user in the snmp-admin login class is not able to configure the [edit interfaces] hierarchy because the permission flags specified for this class do not allow it. In this case, the CLI issues an error message.

Regular Expressions to Allow and Deny Operational Mode Commands, Configuration Statements, and Hierarchies

This topic contains the following sections:

Understanding the Allow and Deny Statements

Each top-level CLI command and configuration statement hierarchy has an access privilege level associated with it. Each login class can explicitly allow or deny the use of operational mode and configuration mode commands and configuration hierarchies and statements that would otherwise be allowed or denied by a privilege level. Users can execute only those commands and view and configure only those statements for which they have access privileges.

The access privileges for each login class are defined by one or more permission flags specified in the permissions statement at the [edit system login class class-name] hierarchy level. In addition, you can allow or deny the use of specific commands and configuration hierarchies by defining extended regular expressions. You can specify the regular expressions by configuring the following statements for a login class:

  • allow-commands and deny-commands—Allow or deny access to operational mode and configuration mode commands.

  • allow-configuration and deny-configuration—Allow or deny access to specific configuration hierarchies.

    Note:

    These statements perform slower matching, with more flexibility, especially in wildcard matching. However, it can take a very long time to evaluate all of the possible statements if a great number of full-path regular expressions or wildcard expressions are configured, possibly negatively affecting performance.

  • allow-commands-regexps and deny-commands-regexps—Allow or deny access to particular commands using strings of regular expressions.

  • allow-configuration-regexps and deny-configuration-regexps—Allow or deny access to specific configuration hierarchies using strings of regular expressions.

Note:

If your existing configurations use the allow/deny-commands or allow/deny-configuration statements, using the same configuration options with the allow/deny-commands-regexps or allow/deny-configuration-regexps statements might not produce the same results. The search and match methods differ in the two forms of these statements.

Explicitly allowing commands and configuration statement hierarchies using the allow/deny-* statements adds to the permissions that the permissions statement already defines. Likewise, explicitly denying commands and configuration statement hierarchies using the allow/deny-* statements removes permissions that the permissions statement already defines.

For example, in the following configuration, the configure permission enables users in the login class to enter configuration mode. Additionally, the allow-configuration expression allows users to modify the configuration at the [edit system services] hierarchy level and commit it.

Similarly, in the following configuration, the login class user can perform all operations that the all permissions flag allows, except that the user cannot view or modify the configuration at the [edit system services] hierarchy level:

Understanding the Allow and Deny Statement Syntax

You can configure an allow/deny-* statement only once in each login class. When you configure a statement:

  • You can configure as many regular expressions as needed.

  • Regular expressions are not case-sensitive

The allow/deny-commands statements are mutually exclusive with the allow/deny-commands-regexps statements, and the allow/deny-configuration statements are mutually exclusive with the allow/deny-configuration-regexps statements. For example, you cannot configure both allow-configuration and allow-configuration-regexps in the same login class.

To define access privileges to commands, specify extended regular expressions using the allow-commands and deny-commands statements. Enclose each complete standalone expression in parentheses ( ), and use the pipe ( | ) symbol to separate the expressions. Do not use spaces between regular expressions that are connected with the pipe symbol. The complete expression is enclosed in double quotation marks.

For example:

You must use anchors when specifying complex regular expressions with the allow-commands statement. For example:

To define access privileges to parts of the configuration hierarchy, specify extended regular expressions in the allow-configuration and deny-configuration statements. Enclose the full paths in parentheses ( ), and use the pipe ( | ) symbol to separate the expressions. Do not use spaces between regular expressions that are connected with the pipe symbol. The complete expression is enclosed in double quotation marks.

For example:

When specifying extended regular expressions using the allow/deny-commands-regexps or allow/deny-configuration-regexps statements, enclose each expression within quotation marks (" "), and separate the expressions using a space. Enclose multiple expressions in square brackets [ ]. For example:

Modifiers such as set, log, and count are not supported within the regular expression string to be matched. If you use a modifier, then nothing is matched.

Correct configuration:

Incorrect configuration:

Understanding the Allow and Deny Statement Precedence and Matching

By default, the allow-commands and allow-configuration regular expressions take precedence over deny-commands and deny-configuration expresssions. Thus, if you configure the same command for both the allow-commands and deny-commands statements, then the allow operation takes precedence over the deny operation. Similarly, if you configure the same statement for both the allow-configuration and deny-configuration statements, then the allow operation takes precedence over the deny operation.

For instance, the following configuration allows a user in the test login class to install software using the request system software add command, even though the deny-commands statement includes the same command:

Similarly, the following configuration allows a user in the test login class test to view and modify the [edit system services] configuration hierarchy, even though the deny-configuration statement includes the same hierarchy:

If the allow-commands and deny-commands statements have two different variants of a command, the longest match is always executed. The following configuration allows a user in the test login class to execute the commit synchronize command but not the commit command. This is because commit synchronize is the longest match between commit and commit synchronize, and it is specified for allow-commands.

The following configuration allows a user in the test login class to execute the commit command but not the commit synchronize command. This is because commit synchronize is the longest match between commit and commit synchronize, and it is specified for deny-commands.

In contrast to the other statements, the default behavior for the *-regexps statements is that the deny-commands-regexps and deny-configuration-regexps regular expressions take precedence over allow-commands-regexps and allow-configuration-regexps expressions. You can configure the regex-additive-logic statement at the [edit system] hierarchy level to force the allow-configuration-regexps regular expressions to take precedence over the the deny-configuration-regexps statements. Configuring the statement enables you to deny configuration hierarchies at a higher level and then only allow the user access to specific sub-hierarchies.

Understanding the Allow and Deny Statement Rules

The allow/deny-commands, allow/deny-configuration, allow/deny-commands-regexps, and allow/deny-configuration-regexps statements take precedence over the login class permissions. When you configure these statements, the following rules apply:

  • Regular expressions for allow-commands and deny-commands statements can also include the commit, load, rollback, save, status, and update commands.

  • The all login class permission bits take precedence over extended regular expressions when a user issues the rollback command with the rollback permission flag enabled.

  • Users cannot issue the load override command when specifying an extended regular expression. Users can only issue the merge, replace, and patch configuration commands.

  • You can use the * wildcard character when denoting regular expressions. However, you must use it as part of a regular expression. You cannot use [ * ] or [ .* ] as the only expression. Additionally, you cannot configure the allow-configuration statement with an expression such as (interfaces (description (|.*)), because this evaluates to allow-configuration .*.

Understanding Differences for the *-regexps Statements

This section outlines the differences between the allow/deny-configuration statements and the allow/deny-configuration-regexps statements.

The allow/deny-configuration-regexps statements split up the regular expression into tokens and match each piece against each part of the specified configuration’s full path, whereas the allow/deny-configuration statements match against the full string. For allow/deny-configuration-regexps statements, you configure a set of strings in which each string is a regular expression, with spaces between the terms of the string. This syntax provides very fast matching but offers less flexibility. For specifying wildcard expressions, you must set up wildcards for each token of the space-delimited string you want to match, which makes it more difficult to use wildcard expressions for these statements.

For example:

  • Regular expression matching one token using allow-configuration-regexps

    This example shows that options is the only matched expression against the first token of the statement.

    The preceding configuration matches the following statements:

    • set policy-options condition condition dynamic-db

    • set routing-options static route static-route next-hop next-hop

    • set event-options generate-event event time-interval seconds

    The preceding configuration does not match the following statements:

    • system host-name host-options

    • interfaces interface-name description options

  • Regular expression matching three tokens using allow-configuration-regexps

    This example shows that ssh is the only matched expression against the third token of the statement.

    In the preceding example, the three tokens include .*, .*, and .*ssh, respectively.

    The preceding configuration matches the following statements:

    • system host-name hostname-ssh

    • system services ssh

    • system services outbound-ssh

    The preceding configuration does not match the following statement:

    • interfaces interface-name description ssh

It is easier to use the deny-configuration statement to restrict configuration access than to use the deny-configuration-regexps statement. Table 2 illustrates the use of both the deny-configuration and deny-configuration-regexps statements in different configurations to achieve the same result of restricting access to a particular configuration.

Table 2: Restricting Configuration Access Using deny-configuration and deny-configuration-regexps Statements

Configuration Denied

Using: deny-configuration

Using: deny-configuration-regexps

Result

xnm-ssl

[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration .*xnm-ssl;
    }
}
[edit system]
login {
    class test {
        permissions configure;
         allow-configuration .*;
        deny-configuration-regexps ".* .* .*-ssl"";
    }
}

The following configuration statement is denied:

  • system services xnm-ssl

ssh

[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration ".*ssh";
    }
}
[edit system]
login {
    class test {
        permissions configure;
        allow-configuration .*;
        deny-configuration-regexps ".*ssh";
        deny-configuration-regexps ".* .*ssh";
        deny-configuration-regexps ".* .* .*ssh";
    }
}

The following configuration statements are denied:

  • system host-name hostname-ssh

  • system services ssh

  • system services outbound-ssh

  • security ssh-known-host

Although the allow/deny-configuration statements are also useful when you want a simple configuration, the allow/deny-configuration-regexps statements provide better performance and overcome the ambiguity that existed when combining expressions in the allow/deny-configuration statements.

Using Regular Expressions on Remote Authorization Servers

You can use extended regular expressions to specify which operational mode and configuration mode commands and configuration statements and hierarchies are allowed or denied for certain users. You specify these regular expressions locally in the allow/deny-commands, allow/deny-configuration, allow/deny-commands-regexps and allow/deny-configuration-regexps statements at the [edit system login class class-name] hierarchy level. You specify these regular expressions remotely by specifying Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your authorization server’s configuration. When you configure authorization parameters both locally and remotely, the device merges the regular expressions received during TACACS+ or RADIUS authorization with any regular expressions defined on the local device.

Note:

Starting in Junos OS Release 18.1, the allow-commands-regexps and deny-commands-regexps statements are supported for TACACS+ authorization.

When specifying multiple regular expressions in a local configuration using the allow-commands, deny-commands, allow-configuration, or deny-configuration statements, you configure regular expressions within parentheses and separate them using the pipe symbol. You enclose the complete expression in double quotation marks. For example, you can specify multiple allow-commands parameters with the following syntax:

The RADIUS authorization server uses the following attributes and syntax:

The TACACS+ authorization server uses the following attributes and syntax:

When specifying multiple regular expressions in a local configuration using the allow-commands-regexps, deny-commands-regexps, allow-configuration-regexps, or deny-configuration-regexps statements, you configure regular expressions within double quotation marks and separate them using the space operator. You enclose the complete expression in square brackets. For example, you can specify multiple allow-commands parameters with the following syntax:

The RADIUS authorization server uses the following attributes and syntax:

The TACACS+ authorization server uses the following attributes and syntax:

RADIUS and TACACS+ servers also support a simplified syntax where you specify each individual expression on a separate line. For example, the RADIUS server simplified syntax is:

Similarly, the TACACS+ server simplified syntax is:

Table 3 differentiates the local authorization configuration and the TACACS+ server authorization configuration using regular expressions.

Table 3: Sample Local and Remote Authorization Configuration Using Regular Expressions

Local Configuration

Remote TACACS+ Configuration

login {
    class local {
        permissions configure;
        allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)";
        deny-commands .*;
        allow-configuration "(interfaces .* unit 0 family ethernet-switching vlan mem.* .*)|(interfaces .* native.* .*)|(interfaces .* unit 0 family ethernet-switching interface-mo.* .*)|(interfaces .* unit .*)|(interfaces .* disable)|(interfaces .* description .*)|(vlans .* vlan-.* .*)"
        deny-configuration .*;
    }
}
user = remote {
    login = username
    service = junos-exec {
        allow-commands1 = "ping .*"
        allow-commands2 = "traceroute .*"
        allow-commands3 = "show .*"
        allow-commands4 = "configure"
        allow-commands5 = "edit"
        allow-commands6 = "exit"
        allow-commands7 = "commit"
        allow-commands8 = ".*xml-mode"
        allow-commands9 = ".*netconf"
        allow-commands10 = ".*need-trailer"
        allow-commands11 = "rollback.*"
        deny-commands1 = ".*"
        allow-configuration1 = "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
        allow-configuration2 = "interfaces .* native.* .*"
        allow-configuration3 = "interfaces .* unit 0 family ethernet-switching interface-mo.* .*"
        allow-configuration4 = "interfaces .* unit .*"
        allow-configuration5 = "interfaces .* disable"
        allow-configuration6 = "interfaces .* description .*"
        allow-configuration7 = "interfaces .*"
        allow-configuration8 = "vlans .* vlan-.* .*"
        deny-configuration1 = ".*"
        local-user-name = local-username
        user-permissions = "configure"
    }
}
Note:
  • You need to explicitly allow access to the NETCONF mode, either locally or remotely, by issuing the following three commands: xml-mode, netconf, and need-trailer.

  • When you use the deny-configuration = ".*" statement, you must allow all the desired configurations using the allow-configuration statement. However, this configuration can affect the allowed regular expressions buffer limit for the allow-configuration statement. If this limit is exceeded, the allowed configuration might not work.

Specify Regular Expressions

Warning:

When you specify regular expressions for commands and configuration statements, pay close attention to the following examples. A regular expression with invalid syntax might not produce the desired results, even if the configuration is committed without any error.

You should specify regular expressions for commands and configuration statements in the same manner as executing the complete command or statement. Table 4 lists the regular expressions for configuring access privileges for the [edit interfaces] and [edit vlans] statement hierarchies and for the delete interfaces command.

Table 4: Specify Regular Expressions

Statement

Regular Expression

Configuration Notes

[edit interfaces]

The set command for interfaces is executed as follows:

[edit]
user@host# set interfaces interface-name unit interface-unit-number

The set interfaces statement is incomplete by itself and requires the unit option to execute the statement.

As a result, the regular expression required for denying the set interfaces configuration must specify the entire executable string with the .* operator in place of statement variables:

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"
  • The .* operator denotes everything from the specified point onward for that particular command or statement. In this example, it denotes any interface name with any unit value.

  • Specifying only the deny-configuration "interfaces .*" statement is incorrect and does not deny access to the interfaces configuration for the specified login class.

  • Other valid options can be included in the regular expression. For example:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set deny-configuration "interfaces .* description .*"
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
    
    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration "interfaces .* unit 0 family ethernet-switching vlan mem.* .*"
    

    Note: The mem.* regular expression in this example is used when multiple strings starting with the mem keyword are expected to be included in the specified regular expression. When only one member string is expected to be included, the member .* regular expression is used.

delete interfaces

The delete command for interfaces is executed as follows:

[edit]
user@host# delete interfaces interface-name

The delete interfaces statement can be executed by itself and does not require additional statements to be complete.

As a result, the regular expression required for denying the delete interfaces statement should specify the following:

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "interfaces .*"
user@host# set deny-configuration "interfaces .*"
  • The .* operator denotes everything from the specified point onward for that particular command or statement. In this example, it denotes any interface name.

  • For the deny-configuration "interfaces .*" regular expression to take effect, the specified login class should allow configuration permissions for the interfaces hierarchy using the allow-configuration "interfaces .*" regular expression.

[edit vlans]

The set command for VLANs is executed as follows:

[edit]
user@host# set vlans vlan-name vlan-id vlan-id

Here, the set vlans statement is incomplete by itself, and requires the vlan-id option to execute the statement.

As a result, the regular expression required for allowing the set vlans configuration must specify the entire executable string with the .* operator in place of statement variables:

[edit system login class class-name]
user@host# set permissions configure
user@host# set allow-configuration "vlans .* vlan-id .*"
  • The .* operator denotes everything from the specified point onward for that particular command or statement. In this example, it denotes any VLAN name with any VLAN ID.

  • Other valid options under the [edit vlans] statement hierarchy can be included in the regular expression. For example:

    [edit system login class class-name]
    user@host# set permissions configure
    user@host# set allow-configuration-regexps [ "vlans .* vlan-id .*" "vlans .* vlan-id .* description .*" "vlans .* vlan-id .* filter .*" ]
    

Regular Expressions Operators

Table 5 lists common regular expression operators that you can use for allowing or denying operational and configuration modes.

Command regular expressions implement the extended (modern) regular expressions, as defined in POSIX 1003.2.

Table 5: Common Regular Expression Operators

Operator

Match

Example

|

One of two or more terms separated by the pipe. Each term must be a complete standalone expression enclosed in parentheses ( ), with no spaces between the pipe and the adjacent parentheses.

[edit system login class test]
user@host# set permissions configure
user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)"
user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)"

With the preceding configuration, the users assigned to the test login class have operational mode access restricted to only the commands specified in the allow-commands statement. They also have access to configuration mode, excluding the hierarchy levels specified in the deny-configuration statement.

^

At the beginning of an expression, used to denote where the command begins, where there might be some ambiguity.

[edit system login class test]
user@host# set permissions interface
user@host# set permissions interface-control
user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)"

With the preceding configuration, the users assigned to the test login class have access to viewing and configuring the interface configuration. The allow-commands statement grants access to commands that begin with the show and monitor keywords.

For the first filter, the commands specified include the show log, show interfaces, and show policer commands. The second filter specifies all commands starting with the monitor keyword, such as the monitor interfaces or the monitor traffic commands.

$

Character at the end of a command. Used to denote a command that must be matched exactly up to that point.

[edit system login class test]
user@host# set permissions interface
user@host# set allow-commands "(show interfaces$)"

With the preceding configuration, the users assigned to the test login class can view the interfaces configuration in configuration mode. The users can also view the interface configuration with the show configuration operational mode command. However, the regular expression specified in the allow-commands statement restricts the users to execute only the show interfaces command and denies access to the command extensions such as show interfaces detail or show interfaces extensive.

[ ]

Range of letters or digits. To separate the start and end of a range, use a hyphen ( - ).

[edit system login class test]
user@host# set permissions clear
user@host# set permissions configure
user@host# set permissions network
user@host# set permissions trace
user@host# set permissions view
user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ]

With the preceding configuration, the users assigned to the test login class have operator-level user permissions. These users also have access to configure interfaces within the specified range of interface name and unit number (0 through 9).

( )

A group of commands indicating a complete, standalone expression to be evaluated. The result is then evaluated as part of the overall expression. Parentheses must be used in conjunction with pipe operators, as explained.

[edit system login class test]
user@host# set permissions all
user@host# set allow-commands "(clear)|(configure)"
user@host# deny-commands "(mtrace)|(start)|(delete)"

With the above configuration, users assigned to the test login class have superuser-level permissions and have access to the commands specified in the allow-commands statement.

*

Zero or more terms.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m*)"

With the above configuration, users assigned to the test login class whose login username begins with m are denied configuration access.

+

One or more terms.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m+)"

With the above configuration, users assigned to the test login class whose login username begins with m are denied configuration access.

.

Any character except for a space " ".

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m.)"

With the above configuration, users assigned to the test login class whose login username begins with m are denied configuration access.

.*

Everything from the specified point onward.

[edit system login class test]
user@host# set permissions configure
user@host# set deny-configuration "(system login class m .*)"

With the above configuration, users assigned to the test login class whose login username begins with m are denied configuration access.

Similarly, the deny-configuration "protocols .*" statement denies all configuration access under the [edit protocols] hierarchy level.

Note:
  • The *, +, and . operations can be achieved by using .*.

  • The deny-commands .* and deny-configuration .* statements deny access to all operational mode commands and configuration hierarchies, respectively.

Note:

The ! regular expression operator is not supported.

Regular Expression Examples

Table 6 lists the regular expressions used to allow configuration options under two configuration hierarchies—[edit system ntp server] and [edit protocols rip]—as an example for specifying regular expressions.

Note:

Table 6 does not provide a comprehensive list of all regular expressions and keywords for all configuration statements and hierarchies. The regular expressions listed in the table are validated only for the [edit system ntp server] and [edit protocols rip] statement hierarchies.

Table 6: Regular Expressions Examples

Statement Hierarchy

Regular Expressions

Allowed Configuration

Denied Configuration

[edit system ntp server]

     

key key-number

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* key .*" ]
set deny-configuration-regexps [ "system ntp server .* version .*" "system ntp server .* prefer" ]
  • server IP

  • server IP and key

  • version

  • prefer

version version-number

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* version .*" ]
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* prefer" ]
  • server IP

  • server IP and version

  • key

  • prefer

prefer

[edit system login class test]
set permissions configure
set allow-configuration-regexps [ "system ntp server .*" "system ntp server .* prefer" ];
set deny-configuration-regexps [ "system ntp server .* key .*" "system ntp server .* version .*" ]
  • server IP

  • server IP and prefer

  • key

  • version

[edit protocols rip]

     

message-size message-size

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip message-size .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • message-size

  • metric-in

  • route-timeout

  • update-interval

metric-in metric-in

[edit system login class test]
set permissions configure
set  allow-configuration-regexps "protocols rip metric-in .*"
set  deny-configuration-regexps [ "protocols rip message-size .*" "protocols rip route-timeout .*" "protocols rip update-interval .*" ]
  • metric-in

  • message-size

  • route-timeout

  • update-interval

route-timeout route-timeout

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip route-timeout .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip message-size .*" "protocols rip update-interval .*" ]
  • route-timeout

  • message-size

  • metric-in

  • update-interval

update-interval update-interval

[edit system login class test]
set permissions configure
set allow-configuration-regexps "protocols rip update-interval .*"
set deny-configuration-regexps [ "protocols rip metric-in .*" "protocols rip route-timeout .*" "protocols rip message-size .*" ]
  • update-interval

  • message-size

  • metric-in

  • route-timeout

How to Define Access Privileges with allow-configuration and deny-configuration Statements

You can define access privileges for configuration statement hierarchies by using a combination of the following types of statements:

  • permission flags

  • allow-configuration and deny-configuration statements

The permission flags define the larger boundaries of what a person or login class can access and control. The allow-configuration and deny-configuration statements contain one or more regular expressions that allow or deny specific configuration hierarchies and statements. The allow-configuration and deny-configuration statements take precedence over permission flags and give the administrator finer control over exactly what hierarchies and statements the user can view and configure.

This topic explains how to define access privileges using allow-configuration and deny-configuration statements by showing examples of login class configurations that use these statements. Examples 1 through 3 create login classes that allow users access to all commands and statements except those defined in the deny-configuration statement.

Notice that permission bit and permission flag are used interchangeably.

Example 1

To create a login class that allows the user to execute all commands and configure everything except telnet parameters:

  1. Set the user’s login class permissions to all.
  2. Include the following deny-configuration statement.

Example 2

To create a login class that allows the user to execute all commands and configure everything except statements within any login class whose name begins with “m”:

  1. Set the user’s login class permissions to all.

  2. Include the following deny-configuration statement.

Example 3

To create a login class that allows the user to execute all commands and configure everything except the [edit system login class] or [edit system services] hierarchy levels:

  1. Set the user’s login class permissions to all.

  2. Include the following deny-configuration statement:

The following examples show how to use the allow-configuration and deny-configuration statements to determine permissions inverse to each other for the [edit system services] hierarchy level.

Example 4

To create a login class that allows the user to have full configuration privileges only at the [edit system services] hierarchy level:

  1. Set the user’s login class permissions to configure.

  2. Include the following allow-configuration statement:

Example 5

To create a login class that allows the user full permissions for all commands and all configuration hierarchies except the [edit system services] hierarchy level:

  1. Set the user’s login class permissions to all.

  2. Include the following deny-configuration statement.

Example: Use Additive Logic with Regular Expressions to Specify Access Privileges

This example shows how to use additive logic when using regular expressions to set up configuration access privileges.

Requirements

This example uses a device running Junos OS Release 16.1 or later.

Overview

You can define regular expressions to control who can make changes to the configuration and what they can change. These regular expressions indicate specific configuration hierarchies that users in a login class are permitted to access. For example, you can define regular expressions that allow users to modify a group of routing instances and define regular expressions that prevent the users from making changes to any other routing instances or to other configuration levels. You define the regular expressions by configuring the allow-configuration-regexps and deny-configuration-regexps statements for a login class.

By default, the deny-configuration-regexps statement takes precedence over the allow-configuration-regexps statement. If a configuration hierarchy appears in a deny-configuration-regexps statement for a login class, it is not visible to the users in that class, regardless of the contents of the allow-configuration-regexps statement. If a configuration hierarchy does not appear in a deny-configuration-regexps statement, it is visible to the users in that class if it appears in an allow-configuration-regexps statement.

You can change this default behavior by enabling additive logic for the *-configuration-regexps statements. When you enable additive logic, the allow-configuration-regexps statement takes precedence over the deny-configuration-regexps statement.

Thus, if the deny-configuration-regexps statement denies access to all configuration hierarchies at a given level (protocols .*) but the allow-configuration-regexps statement allows access to one sub-hierarchy (protocols bgp .*), then by default the device denies access to the hierarchies for users in that login class because the deny-configuration-regexps statement takes precedence. However, if you enable additive logic, the device allows access to the specified sub-hierarchy for users in that login class because the allow-configuration-regexps takes precedence in this case.

Configuration

Step-by-Step Procedure

To enable additive logic to explicitly allow users in a given login class access to one or more individual configuration hierarchies:

  1. Include the deny-configuration-regexps statement, and explicitly deny access to configuration hierarchies.

    For example:

  2. Include the allow-configuration-regexps statement, and define regular expressions for the specific hierarchies to allow.

    For example:

  3. Enable additive logic for the allow-configuration-regexps and deny-configuration-regexps regular expressions.

  4. Assign the login class to one or more users.

  5. Commit your changes.

    Users assigned to this login class have access to the configuration hierarchies included in the allow-configuration-regexps statement but do not have access to the other hierarchies specified in the deny-configuration-regexps statement.

Note:

When you configure the regex-additive-logic statement, the behavior change applies to all allow-configuration-regexps and deny-configuration-regexps statements present in all login classes. If you enable additive logic, you should evaluate existing statements for any impact, and update the regular expressions in those statements as appropriate.

Examples

Use Regular Expressions with Additive Logic

Purpose

This section provides examples of regular expressions that use additive logic to give you ideas for creating configurations appropriate for your system.

Allow Specific Routing Instances

The following example login class includes a regular expression that allows configuration of routing instances whose names start with CUST-VRF-; for example, CUST-VRF-1, CUST-VRF-25, CUST-VRF-100, and so on. The example also includes a regular expression that prevents the configuration of any routing instances.

By default, the deny-configuration-regexps statement takes precedence, and the previous configuration prevents the users in the login class from configuring any routing instances, regardless of the name.

However if you configure the following statement, the allow-configuration-regexps statement takes precedence. Thus, the users can configure routing instances whose names start with CUST-VRF-, but the users cannot configure any other routing instances.

Allow BGP Peer Configuration Only

The following example login class includes regular expressions that prevent configuration at the [edit protocols] hierarchy level but allow configuration of BGP peers:

By default, the previous configuration prevents the users in the login class from making changes to any hierarchies under [edit protocols].

However, if you configure the following statement, the users in the login class can make changes to BGP peers, but the users cannot configure other protocols or other BGP statements outside of the allowed hierarchy level.

Verification

To verify that you have set the access privileges correctly:

  1. Configure a login class and commit the changes.

  2. Assign the login class to a username.

  3. Log in as the username assigned with the new login class.

  4. Attempt to configure the hierarchy levels that are allowed.

    • You should be able to configure statements in hierarchy levels that have been allowed.

    • Hierarchy levels that are denied should not be visible.

    • Any allowed or denied expressions should take precedence over any permissions granted with the permissions statement.

Example: Configure User Permissions with Access Privileges for Operational Mode Commands

This example shows how to configure custom login classes and assign access privileges for operational mode commands. Users in the login class can execute only the commands for which they have access. This prevents unauthorized users from executing sensitive commands that could cause damage to the network.

Requirements

This example uses the following hardware and software components:

  • One Juniper Networks device

  • One TACACS+ (or RADIUS) server

Before you begin, establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS server, establish a UDP connection between the device and the RADIUS server.

Overview and Topology

Figure 1 illustrates a simple topology, where Router R1 is a Juniper Networks device and has a TCP connection established with a TACACS+ server.

Figure 1: Topology Topology

This example configures R1 with three customized login classes: Class1, Class2, and Class3. Each class defines access privileges for the user by configuring the permissions statement and by defining extended regular expressions using the allow-commands and deny-commands statements.

The purpose of each login class is as follows:

  • Class1—Defines access privileges for the user with the allow-commands statement only. This login class provides operator-level user permissions and authorization for rebooting the device.

  • Class2—Defines access privileges for the user with the deny-commands statement only. This login class provides operator-level user permissions and denies access to set commands.

  • Class3—Defines access privileges for the user with both the allow-commands and deny-commands statements. This login class provides superuser-level user permissions and authorization for accessing interfaces and viewing device information. It also denies access to the edit and configure commands.

Router R1 has three different users, User1, User2, and User3 assigned to the Class1, Class2, and Class3 login classes, respectively .

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.

R1

Configure Authentication Parameters for Router R1

Step-by-Step Procedure

To configure Router R1 authentication:

  1. Configure the order in which R1 attempts to authenticate the user. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, and then the local password.

  2. Configure the TACACS+ server.

  3. Configure the RADIUS server.

  4. Configure R1 accounting parameters.

Configure Access Privileges with the allow-commands Statement (Class1)

Step-by-Step Procedure

To specify regular expressions using the allow-commands statement:

  1. Configure the Class1 login class and assign operator-level user permissions.

  2. Configure the allow-commands regular expression to enable users in the class to reboot the device.

  3. Configure the user account for the Class1 login class.

Configure Access Privileges with the deny-commands Statement (Class2)

Step-by-Step Procedure

To specify regular expressions using the deny-commands statement:

  1. Configure the Class2 login class and assign operator-level user permissions.

  2. Configure the deny-commands regular expression to prevent users in the class from executing set commands.

  3. Configure the user account for the Class2 login class.

Configure Access Privileges with Both the allow-commands and deny-commands Statements (Class3)

Step-by-Step Procedure

To specify regular expressions using both the allow-commands and deny-commands statements:

  1. Configure the Class3 login class and assign superuser-level permissions.

  2. Configure the deny-commands regular expression to prevent users in the class from executing any commands.

  3. Configure the allow-commands regular expression to allow users to enter configuration mode.

  4. Configure the user account for the Class3 login class.

Results

In configuration mode, confirm your configuration by entering the show system command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Log in as the username assigned with the new login class, and confirm that the configuration is working properly.

Verifying the Class1 Configuration

Purpose

Verify that the permissions and commands allowed in the Class1 login class are working.

Action

In operational mode, run the show system users command.

In operational mode, run the request system reboot command.

Meaning

The Class1 login class to which User1 is assigned has operator-level user permissions and allows users in the class to execute the request system reboot command.

The predefined operator login class has the following permission flags specified:

  • clear—Can use clear commands to clear (delete) information that the device learns from the network and stores in various network databases.

  • network—Can access the network by using the ping, ssh, telnet, and traceroute commands.

  • reset—Can restart software processes by using the restart command.

  • trace—Can view trace file settings and configure trace file properties.

  • view—Can use various commands to display current system-wide, routing table, and protocol-specific values and statistics. Cannot view the secret configuration.

For the Class1 login class, in addition to the above-mentioned user permissions, User1 can execute the request system reboot command. The first output displays the view permissions as an operator, and the second output shows that the only request system command that User1 can execute as an operator is the request system reboot command.

Verifying the Class2 Configuration

Purpose

Verify that the permissions and commands allowed for the Class2 login class are working.

Action

In operational mode, run the ping command.

From the CLI prompt, check the available commands.

From the CLI prompt, execute any set command.

Meaning

The Class2 login class to which User2 is assigned has operator-level user permissions and denies access to all set commands.

The permission flags specified for the predefined operator login class are the same as those specified for Class1.

Verifying Class3 Configuration

Purpose

Verify that the permissions and commands allowed for the Class3 login class are working.

Action

In operational mode, check the available commands.

Enter configuration mode.

Meaning

The Class3 login class to which User3 is assigned has superuser (all) permissions, but this class only allows users to execute the configure command. The class denies access to all other operational mode commands. Because the regular expressions specified in the allow/deny-commands statements take precedence over the user permissions, User3 on R1 has access only to configuration mode and is denied access to all other operational mode commands.

Example: Configure User Permissions with Access Privileges for Configuration Statements and Hierarchies

This example shows how to configure custom login classes and assign access privileges to specific configuration hierarchies. Users in the login class can view and modify only those configuration statements and hierarchies to which they have access. This prevents unauthorized users from modifying device configurations that could cause damage to the network.

Requirements

This example uses the following hardware and software components:

  • One Juniper Networks device

  • One TACACS+ (or RADIUS) server

Before you begin, establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS server, establish a UDP connection between the device and the RADIUS server.

Overview and Topology

Figure 2 illustrates a simple topology, where Router R1 is a Juniper Networks device and has a TCP connection established with a TACACS+ server.

Figure 2: Topology Topology

This example configures R1 with two customized login classes: Class1 and Class2. Each class defines access privileges for the user by configuring the permissions statement and by defining extended regular expressions using the allow-configuration, deny-configuration, allow-configuration-regexps, and deny-configuration-regexps statements.

The purpose of each login class is as follows:

  • Class1—Defines access privileges for the user with the allow-configuration and deny-configuration statements. This login class provides access to configure the [edit interfaces] hierarchy only and denies all other access on the device. To do this, the user permissions include configure to provide configuration access. In addition, the allow-configuration statement allows access to the interfaces configuration, and the deny-configuration statement denies access to all other configuration hierarchies. Because the allow statement takes precedence over the deny statement, the users assigned to the Class1 login class can access only the [edit interfaces] hierarchy level.

  • Class2—Defines access privileges for the user with the allow-configuration-regexps and deny-configuration-regexps statements. This login class provides superuser-level user permissions and explicitly allows configuration under multiple hierarchy levels for interfaces. It also denies access to the [edit system] and [edit protocols] hierarchy levels.

Router R1 has two users, User1 and User2, assigned to the Class1 and Class2 login classes, respectively.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit in configuration mode.

R1

Configure Authentication Parameters for Router R1

Step-by-Step Procedure

To configure Router R1 authentication:

  1. Configure the order in which R1 attempts to authenticate the user. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, and then the local password.

  2. Configure the TACACS+ server.

  3. Configure the RADIUS server.

  4. Configure the R1 accounting parameters.

Configure Access Privileges with the allow-configuration and deny-configuration Statements (Class1)

Step-by-Step Procedure

To specify regular expressions using the allow-configuration and deny-configuration statements:

  1. Configure the Class1 login class with configure permissions.

  2. Configure the allow-configuration regular expression to allow users in the class to view and modify part of the [edit interfaces] hierarchy level.

  3. Configure the deny-configuration regular expression to deny access to all configuration hierarchies.

  4. Configure the user account for the Class1 login class.

Configure Access Privileges with the allow-configuration-regexps and deny-configuration-regexps Statements (Class2)

Step-by-Step Procedure

To specify regular expressions using the allow-configuration-regexps and deny-configuration-regexps statements:

  1. Configure the Class2 login class and assign superuser (all) permissions.

  2. Configure the allow-configuration-regexps regular expression to allow users in the class to access multiple hierarchies under the [edit interfaces] hierarchy level.

  3. Configure the deny-configuration-regexps regular expression to prevent users in the class from viewing or modifying the configuration at the [edit system] and [edit protocols] hierarchy levels.

  4. Configure the user account for the Class2 login class.

Results

In configuration mode, confirm your configuration by entering the show system command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Log in as the username assigned with the new login class, and confirm that the configuration is working properly.

Verify the Class1 Configuration

Purpose

Verify that the permissions allowed in the Class1 login class are working.

Action

In operational mode, check the available commands.

In configuration mode, check the available configuration permissions.

Meaning

User1 has configure user permissions, as seen in the first output. Additionally, in configuration mode, User1 has access to the interfaces hierarchy level, but only that hierarchy level, as seen in the second output.

Verify the Class2 Configuration

Purpose

Verify that the Class2 configuration is working as expected.

Action

In configuration mode, access the interfaces configuration.

In configuration mode, access the system and protocols configuration hierarchies.

Meaning

User2 has permissions to configure interfaces on R1, but the user does not have permission to view or modify the [edit system] or [edit protocols] hierarchy levels.

Release History Table
Release
Description
18.1
Starting in Junos OS Release 18.1, the allow-commands-regexps and deny-commands-regexps statements are supported for TACACS+ authorization.