Junos OS User Access Privileges

 

Junos OS allows you to grant the access or permissions to the commands and configuration hierarchy levels and statements. This enables users to execute only those commands and configure and view only those statements for which they have access privileges. You can use extended regular expressions to specify which operational mode commands, configuration statements, and hierarchies are denied or allowed for users. This prevents unauthorized users from executing or configuring sensitive commands and statements that could potentially cause damage to the network. Read this topic for more information.

Understanding Junos OS Access Privilege Levels

Each top-level CLI command and each configuration statement have an access privilege level associated with them. Users can execute only those commands and configure and view only those statements for which they have access privileges. The access privileges for each login class are defined by one or more permission flags.

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 specified in the permissions statement.

The following sections provide additional information about permissions:

Junos OS Login Class Permission Flags

Permission flags are used to grant a user access to operational mode commands and 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.

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, so 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 for individual parts of the configuration are:

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

  • Form that ends in -control—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 flags grant read-only privilege to that configuration. For example, the interface permissions flag grants read-only access to the [edit interfaces] hierarchy level. The -control form of the flag grants read-write access to that configuration. Using the preceding example, interface-control grants read-write access to the [edit interfaces] hierarchy level.

Table 1 lists the Junos OS 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 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 configuration mode and with the show configuration operational mode command.

access-control

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

admin

Can view user account information in configuration mode and with the show configuration operational mode command.

admin-control

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

all-control

Can view user accounts and configure them at the [edit system login] hierarchy level.

all

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

clear

Can clear (delete) information learned from the network that is stored in various network databases by using the clear commands.

configure

Can enter configuration mode by using the configure 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 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 configuration mode.

flow-tap-control

Can view the flow-tap configuration in configuration mode and can configure flow-tap configuration 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 the 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 configuration mode and with the show configuration operational mode command.

interface-control

Can view chassis, class of service (CoS), groups, forwarding options, and interfaces configuration information. Can edit 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 router or switch and becoming the superuser in the shell by using the su root command, and can halt and reboot the router or switch by 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 and can configure whether software processes are enabled or disabled at the [edit system processes] hierarchy level.

rollback

Can use the rollback command to return to a previously committed configuration other than the most recently committed one.

routing

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

routing-control

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

secret

Can view passwords and other authentication keys in the configuration.

secret-control

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

security

Can view security configuration in configuration mode and with the show configuration operational mode command.

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 configuration and operational modes.

snmp-control

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

system

Can view system-level information in configuration and operational modes.

system-control

Can view system-level configuration information and configure it 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.

Allowing or Denying Individual Commands for Junos OS Login Classes

By default, all top-level CLI commands have associated access privilege levels. Users can execute only those commands and view only those statements for which they have access privileges. 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 specified in the permissions statement.

Permission flags are used to grant a user access to operational mode commands and 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. For permission flags that grant access to configuration hierarchy levels and statements, the flags grant read-only privilege to that configuration. For example, the interface permissions flag grants read-only access to the [edit interfaces] hierarchy level. The -control form of the flag grants read-write access to that configuration. Using the preceding example, interface-control grants read-write access to the [edit interfaces] hierarchy level.

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

  • Expressions used to allow and deny commands for users on RADIUS and TACACS+ servers have been simplified. Instead of a single, long expression with multiple commands (allow-commands=cmd1 cmd2 ... cmdn), you can specify each command as a separate expression. This new syntax is valid for allow-configuration, deny-configuration, allow-commands, deny-commands, and all user permission bits.

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

  • If you allow and deny the same commands, the allow-commands permissions take precedence over the permissions specified by the deny-commands. For example, if you include allow-commands "request system software add" and deny-commands "request system software add", the login class user is allowed to install software using the request system software add command.

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

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

    For example, if you specify a regular expression for allow-commands with the commit-synchronize command and a regular expression for deny-commands with the commit command, users assigned to such a login class would be able to issue 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.

    Likewise, if you specify a regular expression for allow-commands with the commit command and a regular expression for deny-commands with the commit-synchronize command, users assigned to such a login class would be able to issue 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.

Example: Configuring User Permissions with Access Privilege Levels

This example shows how to view permissions for a user account and configure the user permissions with access privileges for a login class. This enables users to execute only those commands and configure and view only those statements for which they have access privileges. This prevents unauthorized users from executing or configuring sensitive commands and statements that could potentially cause damage to the network.

Requirements

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.

Overview

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.

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:

  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.

Configuration

Configuring User Permissions with Access Privilege Levels

Step-by-Step Procedure

To configure access privileges:

  1. From the device, view the list of permissions available for the user account. In this example, the username of the user account is host.

    The output lists the permissions for the user host. Customized login classes can be created by configuring different access privileges on these user permissions.

  2. Configure an access privilege class to enable user host to configure and view SNMP parameters only. In this example, this login class is called network-management. To customize the network-management login class, include the SNMP permission flags to the configure user permission.

    Here, 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 the network-management login class. In other words, all other access privileges other than configuring and viewing SNMP parameters are denied.

Results

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

Verification

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

Verifying SNMP Configuration

Purpose

Verify that SNMP configuration can be executed.

Action

From configuration mode, execute basic SNMP commands at the [edit snmp] hierarchy level.

Meaning

The user host assigned to the network-management login class is able to configure SNMP parameters, as the permission flags specified for this class include both snmp (read capabilities) and snmp-control (read and write capabilities) permission bits.

Verifying non-SNMP Configuration

Purpose

Verify that non-SNMP configuration is denied for the network-management login class.

Action

From the configuration mode, execute any non-SNMP configuration, for example, interfaces configuration.

Regular Expressions for Allowing and Denying Junos OS Operational Mode Commands, Configuration Statements, and Hierarchies

This topic contains the following sections:

Understanding Regular Expressions

You can use extended regular expressions to specify which operational mode commands, configuration statements, and hierarchies are denied or allowed. You specify these regular expressions locally in the allow/deny-commands, allow/deny-configuration, and allow/deny-commands-regexps and allow/deny-configuration-regexp statements at the [edit system login class class-name] hierarchy level, or remotely by specifying Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your authorization server’s configuration.

Note

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

The difference between a local and remote authorization configuration is the pattern in which the regular expressions statements are executed. While it is possible to specify multiple regular expressions using strings in the local authorization configuration, in a remote configuration, the regular expressions statements need to be split and specified in individual strings. When the authorization parameters are configured both remotely and locally, the regular expressions received during TACACS+ or RADIUS authorization get merged with any regular expressions available on the local device.

When specifying multiple regular expressions in a local configuration using the allow-configuration, deny-configuration, allow-commands, or deny-commands statements, regular expressions are configured within parentheses and separated using the pipe symbol. The complete expression is enclosed in double quotes. For example, you can specify multiple allow-commands parameters with the following syntax:

allow-commands "(cmd1)|(cmd2)|(cmdn)"

The same expression configured remotely on the authorization server uses the following syntax:

When specifying multiple regular expressions in a local configuration using the allow-configuration-regexps, deny-configuration-regexps, allow-commands-regexps, or deny-commands-regexps statements, regular expressions are configured within double quotes and separated using the space operator. The complete expression is enclosed in square brackets. For example, you can specify multiple allow-commands parameters with the following syntax:

The same expression configured remotely on the authorization server uses the following syntax:

Table 2 differentiates the local and remote authorization configuration using regular expressions.

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

Local Configuration

Remote 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 the deny-configuration = “.*” statement is used, all the other desired configurations should be allowed using the allow-configuration statement. This can affect the allowed regular expressions buffer limit for the allow-configuration statement. When this limit exceeds, the allowed configuration might not work. This regular expression buffer size limit has been increased in Junos OS Release 14.1x53-D40, 15.1, and 16.1.

Specifying Regular Expressions

Warning

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

Regular expressions for commands and configuration statements should be specified in the same manner as executing the complete command or statement. Table 3 lists the regular expressions for configuring access privileges for the [edit interfaces] and [edit vlans] statement hierarchies, and for the delete interfaces command.

Table 3: Specifying 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 4 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 4: 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 above configuration, the users assigned to the test login class have operational mode access restricted to only the commands specified in the allow-commands statement, and access to the 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 above configuration, the users assigned to the test login class have access to configuring and viewing interface configuration from the operational and configuration mode. The allow-commands statement specifies access to commands that begin with 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 monitor interfaces or 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 above configuration, the users assigned to the test login class can view the interface configuration in the configuration mode and with the show configuration operational mode command with the interface user permission. 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 above configuration, the users assigned to the test login class have operator-level user permissions, and 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

Junos OS does not support the ! regular expression operator.

Regular Expression Examples

Table 5 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 5 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 supported in Junos OS Release 16.1, and are validated only for the [edit system ntp server] and [edit protocols rip] statement hierarchies.

Table 5: 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

Examples of Defining Access Privileges Using allow-configuration and deny-configuration Statements

You can define access privileges 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 take precedence over permission flags and give the administrator finer control over exactly what the user has access to.

This topic explains defining access privileges using allow-configuration and deny-configuration statements by showing a series of examples of login class configuration using these statements. Examples 1 through 3 use both permission flags and deny-configuration statements to create login classes that allow users access to all except something. Each allow-configuration or deny-configuration statement is configured with one or more regular expressions to be allowed or denied.

Notice that permission bit and permission flag are used interchangeably.

Example 1

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

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

Example 2

To create a login class that allows the user to configure everything except anything within any login class whose name begins with “m”:

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

Example 3

This next example shows the creation of a login class with the all permission bit that prevents the user from editing a configuration or issuing commands (such as commit) at the [edit system login class] or [edit system services] hierarchy levels:

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

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

The next two 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 at the [edit system services] hierarchy level and at only the [edit system services] hierarchy level:

  1. Set the user’s login class permission bit to configure.
  2. Include the following allow-configuration statement.

Example 5

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

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

Example: Using 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 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.

Overview

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.

Configuration

To enable additive logic for regular expressions:

  1. To explicitly allow one or more individual configuration mode hierarchies, include the allow-configuration-regexps statement at the [edit system login class class-name] hierarchy level, configured with the regular expressions to be allowed.
  2. Assign the login class to one or more users.
  3. Enable additive logic for regular expressions.
  4. Commit your changes.

    Users assigned this login class have access to the configuration hierarchies included in the allow-configuration-regexps statement, but no others.

Examples

Using 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:

If the following statement is included in the configuration, it prevents the user from configuring any other routing instances and denies access to any non-routing instance configuration hierarchy:

Allow BGP Peer Configuration Only

The following example login class includes a regular expression that allows configuration of BGP peers:

If the following statement is included in the configuration, it prevents the user from making any other changes, such as deleting or disabling BGP statements:

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 perform the configurations that have been allowed.
    • You should be able to perform configuration changes to hierarchy levels and regular expressions that have been allowed.

    • All other hierarchies should not be visible.

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

Example: Configuring 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. This enables users of the customized login class to execute only those operational commands for which access privileges have been specified. This prevents unauthorized users from executing sensitive commands that could potentially cause damage to the network.

Requirements

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.

Overview and Topology

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

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 from configuration mode.

R1

Configuring Authentication Parameters for Router R1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R1 authentication:

  1. Configure the order in which authentication should take place for R1. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, and then the local password.
  2. Establish R1 connection with the TACACS+ server.
  3. Configure RADIUS server authentication parameters.
  4. Configure R1 accounting configuration parameters.

Configuring Access Privileges with allow-commands Statement Only (Class1)

Step-by-Step Procedure

To specify regular expressions using the allow-commands statement only:

  1. Configure Class1 custom login class and assign operator-level user permissions. For information on the predefined system login classes, see the Junos OS Login Classes Overview.
  2. Specify the command to enable rebooting of R1 in the allow-commands statement.
  3. Configure the user account for the Class1 login class.

Configuring Access Privileges with deny-commands Statement Only (Class2)

Step-by-Step Procedure

To specify regular expressions using the deny-commands statement only:

  1. Configure the Class2 custom login class and assign operator-level user permissions. For information on the predefined system login classes, see the Junos OS Login Classes Overview.
  2. Disable execution of any set commands in the deny-commands statement.
  3. Configure the user account for the Class2 login class.

Configuring Access Privileges with Both 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 custom login class and assign superuser-level user permissions. For information on the predefined system login classes, see the Junos OS Login Classes Overview.
  2. Specify the commands to enable only configure commands in the allow-commands statement.
  3. Disable execution of all commands in the deny-commands statement.
  4. Configure the user account for the Class1 login class.

Results

From 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 Class1 Configuration

Purpose

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

Action

From operational mode, run the show system users command.

User1@R1> show system users

From operational mode, run the request system reboot command.

User1@R1> request system ?

Meaning

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

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

  • clear—Can clear (delete) information learned from the network that is stored in various network databases by using the clear commands.

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

  • reset—Can restart software processes by using the restart command and can configure whether software processes are enabled or disabled at the [edit system processes] hierarchy level.

  • 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 command that User1 can execute as an operator is the request system reboot command.

Verifying Class2 Configuration

Purpose

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

Action

From the operational mode, run the ping command.

User2@R1> ping 10.209.1.66

From the CLI prompt, check the available permissions.

User2@R1> ?

From the CLI prompt, execute any set command.

User2@R1> set

Meaning

The Class2 login class to which User2 is assigned has the operator-level user permissions, and is denied access to all set commands. This is displayed in the command outputs.

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

Verifying Class3 Configuration

Purpose

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

Action

From the CLI prompt, check the available permissions.

User3@R1> ?

From the operational mode, enter configuration mode.

User3@R1> configure

Meaning

The Class3 login class to which User3 is assigned has the superuser (all) user permissions, but is allowed to execute the configure command only, and is denied 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: Configuring User Permissions with Access Privileges for Configuration Statements and Hierarchies

This example shows how to configure custom login classes and assign access privileges to portions of the configuration hierarchy. This enables users of the customized login class to execute only those configuration statements and hierarchies for which access privileges have been specified. This prevents unauthorized users from accessing device configurations that could potentially cause damage to the network.

Requirements

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.

Overview and Topology

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.

Table 6: Restricting Configuration Access Using deny-configurtion 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 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.

Note

The allow/deny-configuration and allow/deny-configuration-regexps statements are mutually exclusive and cannot be configured together for a login class. At a given point in time, a login class can include either the allow/deny-configuration 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.



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

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 from configuration mode.

R1

Configuring Authentication Parameters for Router R1

Step-by-Step Procedure

The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Router R1 authentication:

  1. Configure the order in which authentication should take place for R1. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, then the local password.
  2. Establish R1 connection with the TACACS+ server.
  3. Configure RADIUS server authentication parameters.
  4. Configure the R1 accounting configuration parameters.

Configuring Access Privileges with 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 custom login class and assign configuration user permissions.
  2. Specify the regular expression in the allow-configuration statement to allow configuration at the [edit interfaces] hierarchy level. To allow set commands at the [edit interfaces] hierarchy level, the regular expression used is interfaces .* unit .*.
  3. Specify the regular expression in the deny-configuration statement to disable all configuration access. The regular expression used to deny all configuration access is .*.
  4. Configure the user account for the Class1 login class.

Configuring Access Privileges with 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 custom login class and assign superuser (all) user permissions. For information on the predefined system login classes, see Junos OS Login Classes Overview.
  2. Specify the regular expression to allow access to multiple hierarchies under the [edit interfaces] hierarchy level.
  3. Specify the regular expression to deny configuration at the [edit system] and [edit protocols] hierarchy levels.
  4. Configure the user account for the Class2 login class.

Results

From 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 Class1 Configuration

Purpose

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

Action

From the CLI prompt, check the available permissions.

User1@R1> ?

From the configuration mode, check the available configuration permissions.

User1@R1# edit ?

Meaning

User1 has configure user permissions seen in the first output, and the only configuration access allowed for User1 is at the interfaces hierarchy level. All other configuration is denied, as seen in the second output.

Verifying Class2 Configuration

Purpose

Verify that the Class2 configuration is working.

Action

From the configuration mode, access the interfaces configuration.

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

User2@R1# edit system
User2@R1# edit protocols

Meaning

User2 has permissions to configure interfaces of R1, but the [edit system] and [edit protocols] hierarchy levels are denied access, as seen in the output.