User Access Privileges

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.

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.

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.

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.

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.

[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"";
    }
}

[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";
    }
}

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.

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.

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.*"
        allow-commands12 = "junoscript"
        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"
    }
}

Specify Regular Expressions

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.

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

[edit system login class class-name]
user@host# set permissions configure
user@host# set deny-configuration "interfaces .* unit .*"

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

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

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.

[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)"

[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)"

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

[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 .*" ]

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

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

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

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

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

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.

[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" ]

[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" ]

[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 .*" ]

[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 .*" ]

[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 .*" ]

[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 .*" ]

[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 .*" ]