Junos OS User Access Privileges

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

Before you begin:

• Establish connection between the device and the TACACS+ server.

  For information on configuring a TACACS+ server, see Configuring TACACS+ Authentication.

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more than one login class, each with varying permission configurations, and more than one user on the device.

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has an access privilege level associated with it. For each login class, you can explicitly deny or allow the use of operational and configuration mode commands that would otherwise be permitted or not allowed by a privilege level. Users can execute only those commands and configure and view only those statements for which they have access privileges. To configure access privilege levels, include the permissions statement at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the permissions statement. Permission flags are used to grant a user access to operational mode commands, statements, and configuration hierarchies. Permission flags are not cumulative, so 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 configuration 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.

To configure user access privilege levels:

1. View permissions for a user account.

   You can view the permissions for a user account before configuring the access privileges for those permissions.

   To view the user permissions, enter ? at the [edit] hierarchy level:

2. Configure user permissions with access privileges.

   All users who can log in to a device must be in a login class. For each login class, you can configure the access privileges that the associated users can have when they are logged in to the device.

   To configure access privilege levels for user permissions, include the permissions statement at the [edit system login class class-name] hierarchy level, followed by the user permission, the permissions option, and the required permission flags.

• Configuring User Permissions with Access Privilege Levels
• Results

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

• Verifying SNMP Configuration
• Verifying non-SNMP Configuration

This example uses the following hardware and software components:

• One Juniper Networks J Series, M Series, MX Series, or T Series device

• Junos OS Release 16.1 or later

  • There must be at least one user assigned to a login class.

  • There can be more than one login class, each with varying permission configurations, and more than one user on the device.

To control who can make configuration changes to the system, and what specifically they can change, you can create regular expressions that indicate specific portions of the configuration hierarchy that users in a named user class are permitted to access. For example, you can create regular expressions that specify a group of routing instances that users are allowed to modify, and prevent the users from making changes to any other routing instances, or to any other configuration level.

You configure regular expressions using the allow-configuration-regexps and deny-configuration-regexps statements. By default, deny-configuration-regexps statements take precedence over allow-configuration-regexps statements for users in the named user class to which they are applied.

If a configuration hierarchy appears in a deny-configuration-regexps statement for a named user class, it is not visible to the users, 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 if it appears in an allow-configuration-regexps statement, or if there is no allow-configuration-regexps statement configured for the user class..

You can optionally change this default behavior so additive logic (that is, deny all by default / allow some as specified) is used in regular expressions. When additive logic is enabled, the behavior of existing regular expressions changes so that all configuration hierarchies are denied unless they are included in an allow-configuration-regexps statement for the named user class.

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

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.

  For information on configuring a TACACS+ server, see Configuring TACACS+ Authentication.

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more than one login class, each with varying permission configurations, and more than one user on the device.

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has an access privilege level associated with it. For each login class, you can explicitly deny or allow the use of operational and configuration mode commands that would otherwise be permitted or not allowed by a privilege level. Users can execute only those commands and configure and view only those statements for which they have access privileges. To configure access privilege levels, include the permissions statement at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the permissions statement. In addition to this, you can specify extended regular expressions with the following statements:

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

• allow-configuration and deny-configuration—Allow or deny access to a particular configuration hierarchy only.

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

• allow-commands-regexps and deny-commands-regexps—(TACACS+ authorization only) Allow or deny access to a particular command using strings of regular expressions.

The above statements define a user’s access privileges to individual operational mode commands, configuration statements, and hierarchies. These statements take precedence over the login class permissions set for a user.

Configuration Notes

When configuring the allow-commands, deny-commands, allow-configuration, and deny-configuration statements with access privileges, take the following into consideration:

• You can include the allow/deny statement only once in each login class.

• If the exact same command is configured under both allow-commands and deny-commands statements, or both allow-configuration and deny-configuration statements, then the allow operation takes precedence over the deny statement.

  For instance, with the following configuration, a user assigned to login class test is allowed to install software using the request system software add command, although the deny-commands statement also includes it:

  For instance, with the following configuration, a user assigned to login class test is allowed to access the [edit system services] configuration hierarchy, although the deny-configuration statement also includes it:

• If you specify a regular expression for allow-commands and deny-commands statements with two different variants of a command, the longest match is always executed.

  For instance, for the following configuration, a user assigned to test login class is allowed to execute the commit synchronize command and 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.

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

• Explicitly allowing configuration mode hierarchies or regular expressions using the allow-configuration statement adds to the regular permissions set using the permissions statement. Likewise, explicitly denying configuration mode hierarchies or regular expressions using the deny-configuration statement removes permissions for the specified configuration mode hierarchy, from the default permissions provided by the permissions statement.

  For example, for the following configuration, the login class user can edit the configuration at the [edit system services] hierarchy level and issue configuration mode commands (such as commit), in addition to just entering the configuration mode using the configure command, which is the permission specified by the configure permission flag:

  Likewise, for the following configuration, the login class user can perform all operations allowed by the all permissions flag, except issuing configuration mode commands (such as commit) or modifying the configuration at the [edit system services] hierarchy level:

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

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

• To define access privileges to parts of the configuration hierarchy, specify the full paths in the extended regular expressions with the allow-configuration and deny-configuration statements. Use parentheses around an extended regular expression that connects two or more expressions with the pipe (|) symbol.

  For example:

• If the regular expression contains any spaces, operators, or wildcard characters, enclose the expression in quotation marks. Regular expressions are not case-sensitive; for example, allow-commands "show interfaces".

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

  Incorrect configuration:

  Correct configuration:

• Anchors are required when specifying complex regular expressions with the allow-commands statement.

  For example:

• When specifying extended regular expressions using the allow/deny-commands and allow/deny-configuration statements, 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 example:

• When specifying extended regular expressions using the allow/deny-configuration-regexps or allow/deny-commands-regexps statement, each expression enclosed within quotes (") and separated by a space must be enclosed in angular brackets [ ].

  For example:

• You can use the * wildcard character when denoting regular expressions. However, it must be used as a portion of a regular expression. You cannot use [ * ] or [ .* ] alone.

• You cannot configure the allow-configuration statement with the (interfaces (description (|.*)) regular expression, as this evaluates to allow-configuration = .* regular expression.

• You can configure as many regular expressions as needed to be allowed or denied. Regular expressions to be denied take precedence over configurations to be allowed.

Topology

Figure 1: Configuring TACACS+ Server Authentication

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

In this example, R1 is configured with three customized login classes—Class1, Class2, and Class3—for specifying access privileges with extended regular expressions using the allow-commands and deny-commands statements differently.

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 should provide authorization for only 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 should deny 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 should provide authorization for accessing interfaces and viewing device information. It should also deny access to edit and configure commands.

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

• CLI Quick Configuration
• Configuring Authentication Parameters for Router R1
• Configuring Access Privileges with allow-commands Statement Only (Class1)
• Configuring Access Privileges with deny-commands Statement Only (Class2)
• Configuring Access Privileges with Both allow-commands and deny-commands Statements (Class3)
• Results

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

• Verifying Class1 Configuration
• Verifying Class2 Configuration
• Verifying Class3 Configuration

This example uses the following hardware and software components:

• One Juniper Networks device

• One TACACS+ (or RADIUS) server

• Junos OS build running on the Juniper Networks device

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.

  For information on configuring a TACACS+ server, see Configuring TACACS+ Authentication.

• Configure at least one user assigned to a login class on the Juniper Networks device. There can be more than one login class, each with varying permission configurations, and more than one user on the device.

Each top-level command-line interface (CLI) command and each configuration statement in Junos OS has an access privilege level associated with it. For each login class, you can explicitly deny or allow the use of operational and configuration mode commands that would otherwise be permitted or not allowed by a privilege level. Users can execute only those commands and configure and view only those statements for which they have access privileges. To configure access privilege levels, include the permissions statement at the [edit system login class class-name] hierarchy level.

The access privileges for each login class are defined by one or more permission flags specified in the permissions statement. In addition to this, you can specify extended regular expressions with the following statements:

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

• allow-configuration and deny-configuration—Allow or deny access to parts of the configuration hierarchy.

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

• allow-configuration-regexps and deny-configuration-regexps—Allow or deny access to a particular configuration hierarchy using strings of regular expressions. These statements are similar to allow-configuration and deny-configuration statements, except that in the allow/deny-configuration-regexps statements you can configure sets of strings in which the strings include spaces when using the first set of statements.

The above statements define a user’s access privileges to individual operational mode commands, configuration statements, and hierarchies. These statements take precedence over a login class permissions bit set for a user.

Difference between allow/deny-configuration and allow/deny-configuration-regexps statements

The allow-configuration and deny-configuration statements were introduced before Junos OS Release 7.4. The allow-configuration-regexps and deny-configuration-regexps statements were introduced in Junos OS Release 11.2. In Junos OS Release 11.4, the allow-configuration and deny-configuration statements were deprecated, but because these statements were useful in executing simple configurations, these statements were undeprecated in Junos OS Release 11.4R6, and starting with the 11.4R6 release, both the allow/deny-configuration and the allow/deny-configuration-regexps statements are supported.

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 provides very fast matching, but with less flexibility. For specifying wildcard expressions you must set up wildcards for each token of the space-delimited string you want to match, and this makes it more tedious 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 above 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 above 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 above example, the three tokens include .*, .*, and .*ssh, respectively.

  The above configuration matches the following statements:

  • system host-name hostname-ssh

  • system services ssh

  • system services outbound-ssh

  The above configuration does not match the following statement:

  • interfaces interface-name description ssh

You can restrict configuration access easily using the deny-configuration statement as compared to using the deny-configuration-regexps statement. Table 6 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 simple configuration is desired, the allow/deny-configuration-regexps statements provide better performance and overcome the ambiguity that existed when combining expressions set in the allow/deny-configuration statements.

Configuration Notes

When configuring the allow-configuration, deny-configuration, allow-configuration-regexps, and deny-configuration-regexps statements with access privileges, take the following into consideration:

• You can include one deny-configuration and one allow-configuration statement in each login class.

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

• Explicitly allowing configuration mode hierarchies or regular expressions using the allow-configuration statement adds to the regular permissions set using the permissions statement. Likewise, explicitly denying configuration mode hierarchies or regular expressions using the deny-configuration statement removes permissions for the specified configuration mode hierarchy, from the default permissions provided by the permissions statement.

  For example, for the following configuration, the login class user can edit the configuration at the [edit system services] hierarchy level and issue configuration mode commands (such as commit), in addition to just entering the configuration mode using the configure command, which is the permission specified by the configure permission flag:

  Likewise, for the following configuration, the login class user can perform all operations allowed by the all permissions flag, except issuing configuration mode commands (such as commit) or modifying the configuration at the [edit system services] hierarchy level:

• To define access privileges to parts of the configuration hierarchy, specify the full paths in the extended regular expressions with the allow-configuration and deny-configuration statements. Use parentheses around an extended regular expression that connects two or more expressions with the pipe (|) symbol.

  For example:

• When specifying extended regular expressions using the allow/deny-commands and allow/deny-configuration statements, 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 example:

• When specifying extended regular expressions using the allow-deny-configuration-regexps statement, each expression enclosed within quotes (") and separated by a space must be enclosed in angular brackets [ ].

  For example:

• If the exact same command is configured under both allow-configuration and deny-configuration statements, then the allow operation takes precedence over the deny statement.

  For instance, with the following configuration, a user assigned to login class test is allowed to access the [edit system services] configuration hierarchy, although the deny-configuration statement also includes it:

  For instance, if a certain command or configuration is allowed, for example, using permission all, then we can use the deny-configuration command to deny access to a particular hierarchy.

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

  Incorrect configuration:

  Correct configuration:

• You can use the * wildcard character when denoting regular expressions. However, it must be used as a portion of a regular expression. You cannot use [ * ] or [ .* ] alone.

• You cannot configure the allow-configuration statement with the (interfaces (description (|.*)) regular expression, as this evaluates to allow-configuration = .* regular expression.

• You can configure as many regular expressions as needed to be allowed or denied. Regular expressions to be denied take precedence over configurations to be allowed.

Topology

Figure 2: Configuring TACACS+ Server Authentication

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

In this example, R1 is configured with two customized login classes—Class1 and Class2—for specifying access privileges with extended regular expressions using the allow-configuration, deny-configuration, allow-configuration-regexps, and deny-configuration-regexps statements differently.

The purpose of the login classes is as follows:

• Class1—Define access privileges for the user with the allow-configuration and deny-configuration statements. This login class should provide access to configure interfaces hierarchy only, and deny all other access on the device. To do this, the user permissions should include configure to provide configuration access. In addition to this, the allow-configuration statement should allow interfaces configuration, and the deny-configuration statement should deny access to all other configurations. 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—Define access privileges for the user with the allow-configuration-regexps and deny-configuration-regexps statements. This login class provides superuser-level user permissions, and in addition, explicitly allows configuration under multiple hierarchy levels for interfaces. It also denies configuration 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.

• CLI Quick Configuration
• Configuring Authentication Parameters for Router R1
• Configuring Access Privileges with allow-configuration and deny-configuration Statements (Class1)
• Configuring Access Privileges with allow-configuration-regexps and deny-configuration-regexps Statements (Class2)
• Results

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

• Verifying Class1 Configuration
• Verifying Class2 Configuration