ON THIS PAGE
Example: Configuring User Permissions with Access Privilege Levels
Examples of Defining Access Privileges Using allow-configuration and deny-configuration Statements
Example: Using Additive Logic With Regular Expressions to Specify Access Privileges
Example: Configuring User Permissions with Access Privileges for Operational Mode Commands
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
- Allowing or Denying Individual Commands for Junos OS Login Classes
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.
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 isinterface-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.
Permission Flag |
Description |
---|---|
Can view the access configuration in configuration mode and
with the |
|
Can view and configure access information at the |
|
Can view user account information in configuration mode and
with the |
|
Can view user account information and configure it at the |
|
Can view user accounts and configure them at the |
|
|
Can access all operational mode commands and configuration mode commands. Can modify configuration in all the configuration hierarchy levels. |
Can clear (delete) information learned from the network that
is stored in various network databases by using the |
|
Can enter configuration mode by using the |
|
Can perform all control-level operations—all operations
configured with the |
|
Can view field debug commands. Reserved for debugging support. |
|
Can view the firewall filter configuration in configuration mode. |
|
Can view and configure firewall filter information at the |
|
Can read from and write to the removable media. |
|
Can view the flow-tap configuration in configuration mode. |
|
Can view the flow-tap configuration in configuration mode and
can configure flow-tap configuration information at the |
|
Can make flow-tap requests to the router or switch. For example,
a Dynamic Tasking Control Protocol (DTCP) client must have Note:
The |
|
Can view profiler data. |
|
Can view the interface configuration in configuration mode and
with the |
|
Can view chassis, class of service (CoS), groups, forwarding options, and interfaces configuration information. Can edit configuration at the following hierarchy levels:
|
|
Can perform system maintenance, including starting a local shell
on the router or switch and becoming the superuser in the shell by
using the |
|
Can access the network by using the |
|
Can view the |
|
Can modify the |
|
Can restart software processes by using the |
|
Can use the |
|
Can view general routing, routing protocol, and routing policy configuration information in configuration and operational modes. |
|
Can view general routing, routing protocol, and routing policy
configuration information and can configure general routing at the |
|
Can view passwords and other authentication keys in the configuration. |
|
Can view passwords and other authentication keys in the configuration and can modify them in configuration mode. |
|
Can view security configuration in configuration mode and with
the |
|
Can view and configure security information at the |
|
Can start a local shell on the router or switch by using the |
|
Can view Simple Network Management Protocol (SNMP) configuration information in configuration and operational modes. |
|
Can view SNMP configuration information and can modify SNMP
configuration at the |
|
Can view system-level information in configuration and operational modes. |
|
Can view system-level configuration information and configure
it at the |
|
Can view trace file settings and configure trace file properties. |
|
Can modify trace file settings and configure trace file properties. |
|
Can use various commands to display current system-wide, routing table, and protocol-specific values and statistics. Cannot view the secret configuration. |
|
Can view all of the configuration excluding secrets, system scripts, and event options. Note:
Only users with the |
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 issuesrollback
command withrollback
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 forallow-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 themerge
,replace
, andpatch
configuration commands.If you allow and deny the same commands, the
allow-commands
permissions take precedence over the permissions specified by thedeny-commands
. For example, if you includeallow-commands "request system software add"
anddeny-commands "request system software add"
, the login class user is allowed to install software using therequest system software add
command.Regular expressions for
allow-commands
anddeny-commands
can also include thecommit
,load
,rollback
,save
,status
, andupdate
commands.If you specify a regular expression for
allow-commands
anddeny-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 thecommit-synchronize
command and a regular expression fordeny-commands
with thecommit
command, users assigned to such a login class would be able to issue thecommit synchronize
command, but not thecommit
command. This is becausecommit-synchronize
is the longest match betweencommit
andcommit-synchronize
and it is specified forallow-commands
.Likewise, if you specify a regular expression for
allow-commands
with thecommit
command and a regular expression fordeny-commands
with thecommit-synchronize
command, users assigned to such a login class would be able to issue thecommit
command, but not thecommit-synchronize
command. This is becausecommit-synchronize
is the longest match betweencommit
andcommit-synchronize
and it is specified fordeny-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.
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:
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:[edit] ?
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, thepermissions
option, and the required permission flags.[edit system login] user@host# set class class-name permissions user-permission permissions [permission flags];
Configuration
Configuring User Permissions with Access Privilege Levels
Step-by-Step Procedure
To configure access privileges:
From the device, view the list of permissions available for the user account. In this example, the username of the user account is host.
[edit] user@host> ? Possible completions: clear Clear information in the system configure Manipulate software configuration information file Perform file operations help Provide help information load Load information from file monitor Show real-time debugging information mtrace Trace multicast path from source to receiver op Invoke an operation script ping Ping remote target quit Exit the management session request Make system-level requests restart Restart software process save Save information to file set Set CLI properties, date/time, craft interface message show Show system information ssh Start secure shell on another host start Start shell telnet Telnet to another host test Perform diagnostic debugging traceroute Trace route to remote 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.
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.[edit system login class network-management] user@host# set permissions configure permissions snmp user@host# set permissions configure permissions snmp-control
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.
user@host# show system login class network-management { permissions [ configure snmp snmp-control ]; }
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.
[edit snmp] user@host# set name device1 user@host# set description switch1 user@host# set location Lab1 user@host# set contact example.com user@host# commit
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.
[edit] user@host# edit interfaces Syntax error, expecting <statement> or <identifier>.
Regular Expressions for Allowing and Denying Junos OS Operational Mode Commands, Configuration Statements, and Hierarchies
This topic contains the following sections:
- Understanding Regular Expressions
- Specifying Regular Expressions
- Regular Expressions Operators
- Regular Expression Examples
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.
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:
allow-commands1 = "cmd1" allow-commands2 = "cmd2" allow-commandsn = "cmdn"
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:
allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]
The same expression configured remotely on the authorization server uses the following syntax:
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Table 2 differentiates the 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" } } |
You need to explicitly allow access to the NETCONF mode, either locally or remotely, by issuing the following three commands:
xml-mode
,netconf
, andneed-trailer
.When the
deny-configuration = “.*”
statement is used, all the other desired configurations should be allowed using theallow-configuration
statement. This can affect the allowed regular expressions buffer limit for theallow-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
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.
Statement |
Regular Expression |
Configuration Notes |
---|---|---|
[edit interfaces] The [edit] user@host# set interfaces interface-name unit interface-unit-number |
The As a result, the regular expression required for denying the [edit system login class class-name] user@host# set permissions configure user@host# set deny-configuration "interfaces .* unit .*" |
|
delete interfaces The [edit] user@host# delete interfaces interface-name |
The As a result, the regular expression required for denying the [edit system login class class-name] user@host# set permissions configure user@host# set allow-configuration "interfaces .*" user@host# set deny-configuration "interfaces .*" |
|
[edit vlans] The [edit] user@host# set vlans vlan-name vlan-id vlan-id |
Here, the As a result, the regular expression required for allowing the [edit system login class class-name] user@host# set permissions configure user@host# set allow-configuration "vlans .* vlan-id .*" |
|
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.
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 |
^ |
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 For the first filter, the commands specified include the |
$ |
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 |
[ ] |
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 |
* |
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 |
+ |
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 |
. |
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 |
.* |
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 Similarly, the 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.
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.
Statement Hierarchy |
Regular Expressions |
Allowed Configuration |
Denied Configuration |
---|---|---|---|
|
|||
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" ] |
|
|
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" ] |
|
|
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 .*" ] |
|
|
|
|||
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 .*" ] |
|
|
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 .*" ] |
|
|
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 .*" ] |
|
|
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 .*" ] |
|
|
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
anddeny-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:
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”:
Set the user’s login class permission bit to
all
.[edit system login] user@host# set class all-except-login-class-m permissions all
Include the following
deny-configuration
statement.[edit system login class all-except-login-class-m] user@host# set deny-configuration "system login class m.*"
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:
Set the user’s login class permission bit to
all
.[edit system login] user@host# set class all-except-login-class-or-system-services permissions all
Include the following
deny-configuration
statement.[edit system login class all-except-login-class-or-system-services] user@host# set deny-configuration "(system login class) | (system services)"
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:
Set the user’s login class permission bit to
configure
.[edit system login] user@host# set class configure-only-system-services permissions configure
Include the following
allow-configuration
statement.[edit system login class configure-only-system-services] user@host# set allow-configuration "system services"
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:
Set the user’s login class permission bit to
all
.[edit system login] user@host# set class all-except-system-services permissions all
Include the following
deny-configuration
statement.[edit system login class all-except-system-services] user@host# set deny-configuration "system services"
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.
Configuration
Step-by-Step Procedure
To enable additive logic for regular expressions:
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.[edit system login class class-name] user@host# set allow-configuration-regexps "regular expression 1" "regular expression 2" "regular expression 3" "regular expression 4" ...
Assign the login class to one or more users.
[edit system login] user@host# set user username class class-name
Enable additive logic for regular expressions.
[edit system] user@host# set regex-additive-logic
Commit your changes.
Users assigned this login class have access to the configuration hierarchies included in the
allow-configuration-regexps
statement, but no others.
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.
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:
[edit system login class class-name] user@host# set permissions configure view view-configuration user@host# set allow-configuration-regexps "routing-instances CUST-VRF-.* .*"
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:
[edit system] user@host# set regex-additive-logic
Allow BGP Peer Configuration Only
The following example login class includes a regular expression that allows configuration of BGP peers:
[edit system login class class-name] user@host# set permissions configure view view-configuration user@host# set allow-configuration-regexps "protocols bgp group *"
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:
[edit system] user@host# set regex-additive-logic
Verification
To verify that you have set the access privileges correctly:
Configure a login class and commit the changes.
Assign the login class to a username.
Log in as the username assigned with the new login class.
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
anddeny-commands
—Allow or deny access to operational mode commands only.allow-configuration
anddeny-configuration
—Allow or deny access to a particular configuration hierarchy only.allow-configuration-regexps
anddeny-configuration-regexps
—Allow or deny access to a particular configuration hierarchy using strings of regular expressions.allow-commands-regexps
anddeny-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
anddeny-commands
statements, or bothallow-configuration
anddeny-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 thedeny-commands
statement also includes it:[edit system login] user@host# set class test permissions allow-commands "request system software add" user@host# set class test permissions deny-commands "request system software add"
For instance, with the following configuration, a user assigned to login class test is allowed to access the
[edit system services]
configuration hierarchy, although thedeny-configuration
statement also includes it:[edit system login] user@host# set class test permissions allow-configuration "system services" user@host# set class test permissions deny-configuration "system services"
If you specify a regular expression for
allow-commands
anddeny-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 thecommit
command. This is becausecommit-synchronize
is the longest match betweencommit
andcommit-synchronize
, and it is specified forallow-commands
.[edit system login] user@host# set class test allow-commands "commit-synchronize" user@host# set class test deny-commands commit
Regular expressions for
allow-commands
anddeny-commands
statements can also include thecommit
,load
,rollback
,save
,status
, andupdate
commands.Explicitly allowing configuration mode hierarchies or regular expressions using the
allow-configuration
statement adds to the regular permissions set using thepermissions
statement. Likewise, explicitly denying configuration mode hierarchies or regular expressions using thedeny-configuration
statement removes permissions for the specified configuration mode hierarchy, from the default permissions provided by thepermissions
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 ascommit
), in addition to just entering the configuration mode using theconfigure
command, which is the permission specified by the configure permission flag:[edit system login] user@host# set class test permissions configure allow-configuration "system services"
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:[edit system login] user@host# set class test permissions all deny-configuration "system services"
The
allow/deny-configuration
statements are mutually exclusive with theallow/deny-configuration-regexps
statements, and theallow-deny-commands
statements are mutually exclusive with theallow/deny-commands-regexps
statements. For example, you cannot configure bothallow-configuration
andallow-configuration-regexps
in the same login class.If you have existing configurations using the
allow/deny-configuration
orallow/deny-commands
statements, using the same configuration options with theallow/deny-configuration-regexps
orallow/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
anddeny-configuration
statements. Use parentheses around an extended regular expression that connects two or more expressions with the pipe (|) symbol.For example:
[edit system login] user@host# set class test deny-configuration "(system login class) | (system services)"
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:
[edit system login] user@host# set class test permission deny-commands "set protocols"
Correct configuration:
[edit system login] user@host# set class test permission deny-commands protocols
Anchors are required when specifying complex regular expressions with the
allow-commands
statement.For example:
[edit system login] user@host# set class test permissions allow-commands "(^monitor) | (^ping) | (^show) | (^exit)" OR set class test permissions allow-commands "allow-commands ="^(monitor | ping | show | exit)"
When specifying extended regular expressions using the
allow/deny-commands
andallow/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:
[edit system login] user@host# set class test allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)" user@host# set class test deny-configuration "(system login class)|(system services)"
When specifying extended regular expressions using the
allow/deny-configuration-regexps
orallow/deny-commands-regexps
statement, each expression enclosed within quotes (") and separated by a space must be enclosed in angular brackets [ ].For example:
[edit system login] user@host# set class test allow-configuration-regexps [ "interfaces .* description .*” “interfaces .* unit .* description .*” “interfaces .* unit .* family inet address .*” “interfaces.* disable" ]
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 toallow-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 9 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 toset
commands.Class3—Defines access privileges for the user with both the
allow-commands
anddeny-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 toedit
andconfigure
commands.
Router R1 has three different users, User1, User2, and User3, assigned to Class1, Class2, and Class3 login classes, respectively.
Configuration
- 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
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
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 set system login class Class1 permissions clear set system login class Class1 permissions network set system login class Class1 permissions reset set system login class Class1 permissions trace set system login class Class1 permissions view set system login class Class1 allow-commands "request system reboot" set system login class Class2 permissions clear set system login class Class2 permissions network set system login class Class2 permissions reset set system login class Class2 permissions trace set system login class Class2 permissions view set system login class Class2 deny-commands set set system login class Class3 permissions all set system login class Class3 allow-commands configure set system login class Class3 deny-commands .* set system login user User1 uid 2001 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2002 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system login user User3 uid 2003 set system login user User3 class Class3 set system login user User3 authentication encrypted-password "$ABC123" set system syslog file messages any any
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:
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.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
Establish R1 connection with the TACACS+ server.
[edit system] user@R1# set tacplus-server 10.209.1.66 user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66
Configure RADIUS server authentication parameters.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
Configure R1 accounting configuration parameters.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
Configuring Access Privileges with allow-commands Statement Only (Class1)
Step-by-Step Procedure
To specify regular expressions using the allow-commands
statement only:
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.
[edit system login] user@R1# set class Class1 permissions clear user@R1t# set class Class1 permissions network user@R1# set class Class1 permissions reset user@R1# set class Class1 permissions trace user@R1# set class Class1 permissions view
Specify the command to enable rebooting of R1 in the
allow-commands
statement.[edit system login] user@R1# set class Class1 allow-commands "request system reboot"
Configure the user account for the Class1 login class.
[edit system login] user@R1# set user User1 uid 2001 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Configuring Access Privileges with deny-commands Statement Only (Class2)
Step-by-Step Procedure
To specify regular expressions using the deny-commands
statement only:
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.
[edit system login] user@R1# set class Class1 permissions clear user@R1# set class Class1 permissions network user@R1# set class Class1 permissions reset user@R1# set class Class1 permissions trace user@R1# set class Class1 permissions view
Disable execution of any set commands in the
deny-commands
statement.[edit system login] user@R1# set class Class1 deny-commands "set"
Configure the user account for the Class2 login class.
user@R1# set login user User2 uid 2002 user@R1# set login user User2 class Class2 user@R1# set login user User2 authentication encrypted-password "$ABC123"
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:
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.
[edit system login] user@R1# set class Class3 permissions all
Specify the commands to enable only configure commands in the
allow-commands
statement.[edit system login] user@R1# set class Class3 allow-commands configure
Disable execution of all commands in the
deny-commands
statement.[edit system login] user@R1# set class Class3 deny-commands .*
Configure the user account for the Class1 login class.
[edit system login] user@R1# set login user User3 uid 2003 user@R1# set login user User3 class Class3 user@R1# set login user User3 authentication encrypted-password "$ABC123"
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.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66; } } } } login { class Class1 { permissions [ clear network reset trace view ]; allow-commands "request system reboot"; } class Class2 { permissions [ clear network reset trace view ]; deny-commands set; } class Class3 { permissions all; allow-commands configure; deny-commands .*; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } user User3 { uid 2003; class Class3; authentication { encrypted-password “$ABC123”; } } } syslog { file messages { any any; } }
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 12:39PM up 6 days, 23 mins, 6 users, load averages: 0.00, 0.01, 0.00 USER TTY FROM LOGIN@ IDLE WHAT User1 p0 abc.example.net 12:34AM 12:04 cli User2 p1 abc.example.net 12:36AM 12:02 -cli (cli) User3 p2 abc.example.net 10:41AM 11 -cli (cli)
From operational mode, run the request system reboot
command.
User1@R1> request system ? Possible completions: reboot Reboot the 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
, andtraceroute
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 ping 10.209.1.66 PING 10.209.1.66 (10.209.1.66): 56 data bytes 64 bytes from 10.209.1.66: icmp_seq=0 ttl=52 time=212.521 ms 64 bytes from 10.209.1.66: icmp_seq=1 ttl=52 time=212.844 ms 64 bytes from 10.209.1.66: icmp_seq=2 ttl=52 time=211.304 ms 64 bytes from 10.209.1.66: icmp_seq=3 ttl=52 time=210.963 ms ^C --- 10.209.1.66 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 210.963/211.908/212.844/0.792 ms
From the CLI prompt, check the available permissions.
User2@R1> ? Possible completions: clear Clear information in the system file Perform file operations help Provide help information load Load information from file monitor Show real-time debugging information mtrace Trace multicast path from source to receiver op Invoke an operation script ping Ping remote target quit Exit the management session request Make system-level requests restart Restart software process save Save information to file show Show system information ssh Start secure shell on another host start Start shell telnet Telnet to another host test Perform diagnostic debugging traceroute Trace route to remote host
From the CLI prompt, execute any set command.
User2@R1> set ^ unknown command.
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> ? Possible completions: configure Manipulate software configuration information
From the operational mode, enter configuration mode.
User3@R1> configure Entering configuration mode [edit] User3@R1#
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
anddeny-commands
—Allow or deny access to operational mode commands.allow-configuration
anddeny-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
anddeny-configuration-regexps
—Allow or deny access to a particular configuration hierarchy using strings of regular expressions. These statements are similar toallow-configuration
anddeny-configuration
statements, except that in theallow/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.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
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.[edit system] login { class test { permissions configure; allow-configuration-regexps ".* .* .*ssh"; } }
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.
Configuration Denied |
Using: deny-configuration |
Using: deny-configuration-regexps |
Result |
|
[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:
|
|
[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:
|
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.
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 oneallow-configuration
statement in each login class.The
allow/deny-configuration
andallow/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 theallow/deny-configuration
statement, or theallow/deny-configuration-regexps
statement. If you have existing configurations using theallow/deny-configuration
statements, using the same configuration options with theallow/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 thepermissions
statement. Likewise, explicitly denying configuration mode hierarchies or regular expressions using thedeny-configuration
statement removes permissions for the specified configuration mode hierarchy, from the default permissions provided by thepermissions
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 ascommit
), in addition to just entering the configuration mode using theconfigure
command, which is the permission specified by the configure permission flag:[edit system login] user@host# set class test permissions configure allow-configuration "system services"
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:[edit system login] user@host# set class test permissions all deny-configuration "system services"
To define access privileges to parts of the configuration hierarchy, specify the full paths in the extended regular expressions with the
allow-configuration
anddeny-configuration
statements. Use parentheses around an extended regular expression that connects two or more expressions with the pipe (|) symbol.For example:
[edit system login] user@host# set class test deny-configuration "(system login class)|(system services)"
When specifying extended regular expressions using the
allow/deny-commands
andallow/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:
[edit system login] user@host# set class test allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)" user@host# set class test deny-configuration "(system login class)|(system services)"
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:
[edit system login] user@host# set class test allow-configuration-regexps [ "interfaces .* description .*” “interfaces .* unit .* description .*” “interfaces .* unit .* family inet address .*” “interfaces.* disable" ]
If the exact same command is configured under both
allow-configuration
anddeny-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 thedeny-configuration
statement also includes it:[edit system login] user@host# set class test permissions allow-configuration "system services" user@host# set class test permissions deny-configuration "system services"
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:
[edit system login] user@host# set class test permission deny-configuration "set protocols"
Correct configuration:
[edit system login] user@host# set class test permission deny-configuration protocols
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 toallow-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 23 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
anddeny-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, theallow-configuration
statement should allow interfaces configuration, and thedeny-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
anddeny-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
- 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
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
set system authentication-order tacplus set system authentication-order radius set system authentication-order password set system radius-server 10.209.1.66 secret "$ABC123" set system tacplus-server 10.209.1.66 set system radius-options enhanced-accounting set system tacplus-options enhanced-accounting set system accounting events login set system accounting events change-log set system accounting events interactive-commands set system accounting traceoptions file auditlog set system accounting traceoptions flag all set system accounting destination tacplus server 10.209.1.66 set system login class Class1 permissions configure set system login class Class1 allow-configuration "interfaces .* unit .*" set system login class Class1 deny-configuration .* set system login class Class2 permissions all set system login class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ] set system login class Class2 deny-configuration-regexps [ "system" "protocols" ] set system login user User1 uid 2004 set system login user User1 class Class1 set system login user User1 authentication encrypted-password "$ABC123" set system login user User2 uid 2006 set system login user User2 class Class2 set system login user User2 authentication encrypted-password "$ABC123" set system syslog file messages any any
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:
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.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
Establish R1 connection with the TACACS+ server.
[edit system] user@R1# set tacplus-server 10.209.1.66 user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66
Configure RADIUS server authentication parameters.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
Configure the R1 accounting configuration parameters.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands user@R1# set accounting traceoptions file auditlog user@R1# set accounting traceoptions flag all
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:
Configure the Class1 custom login class and assign configuration user permissions.
[edit system login] user@R1# set class Class1 permissions configure
Specify the regular expression in the
allow-configuration
statement to allow configuration at the[edit interfaces]
hierarchy level. To allowset
commands at the[edit interfaces]
hierarchy level, the regular expression used isinterfaces .* unit .*
.[edit system login] user@R1# set class Class1 allow-configuration "interfaces .* unit .*"
Specify the regular expression in the
deny-configuration
statement to disable all configuration access. The regular expression used to deny all configuration access is.*
.[edit system login] user@R1# set class Class1 deny-configuration .*
Configure the user account for the Class1 login class.
[edit system login] user@R1# set system login user User1 uid 2004 user@R1# set system login user User1 class Class1 user@R1# set system login user User1 authentication encrypted-password "$ABC123"
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:
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.
[edit system login] user@R1# set class Class2 permissions all
Specify the regular expression to allow access to multiple hierarchies under the
[edit interfaces]
hierarchy level.[edit system login] user@R1# set class Class2 allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]
Specify the regular expression to deny configuration at the
[edit system]
and[edit protocols]
hierarchy levels.[edit system login] user@R1# set class Class2 deny-configuration-regexps [ "system" "protocols" ]
Configure the user account for the Class2 login class.
[edit system login] user@R1# set system login user User2 uid 2006 user@R1# set system login user User2 class Class2 user@R1# set system login user User2 authentication encrypted-password "$ABC123"
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.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; traceoptions { file auditlog; flag all; } destination { tacplus { server { 10.209.1.66; } } } } login { class Class1 { permissions configure; allow-configuration "interfaces .* unit .*"; deny-configuration .*; } class Class2 { permissions all; allow-configuration-regexps [ "interfaces .* description .*" "interfaces .* unit .* description .*" "interfaces .* unit .* family inet address .*" "interfaces.* disable" ]; deny-configuration-regexps [ "system" "protocols" ]; } user User1 { uid 2001; class Class1; authentication { encrypted-password "$ABC123"; } } user User2 { uid 2002; class Class2; authentication { encrypted-password "$ABC123"; } } } syslog { file messages { any any; } }
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> ? Possible completions: clear Clear information in the system configure Manipulate software configuration information file Perform file operations help Provide help information load Load information from file op Invoke an operation script quit Exit the management session request Make system-level requests save Save information to file set Set CLI properties, date/time, craft interface message start Start shell test Perform diagnostic debugging
From the configuration mode, check the available configuration permissions.
User1@R1# edit ? Possible completions: > interfaces Interface configuration
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.
[edit interfaces] User2@R1# set ? Possible completions: <interface-name> Interface name + apply-groups Groups from which to inherit configuration data + apply-groups-except Don't inherit configuration data from these groups ge-0/0/3 Interface name > interface-range Interface ranges configuration > interface-set Logical interface set configuration > traceoptions Interface trace options
From the configuration mode, access the system and protocols configuration hierarchies.
User2@R1# edit system ^ Syntax error, expecting <statement> or <identifier>. User2@R1# edit protocols ^ Syntax error, expecting <statement> or <identifier>.
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.