ON THIS PAGE
Example: Configure User Permissions with Access Privilege Levels
How to Define Access Privileges with allow-configuration and deny-configuration Statements
Example: Use Additive Logic with Regular Expressions to Specify Access Privileges
Example: Configure User Permissions with Access Privileges for Operational Mode Commands
User Access Privileges
You (the system administrator) grant users access or permissions to commands and configuration hierarchy levels and statements. Users can execute only those commands and view and configure only those statements for which they have access privileges. You can also use extended regular expressions to specify which operational mode commands, configuration statements, and hierarchies are allowed or denied for users. This practice prevents unauthorized users from executing sensitive commands or configuring statements that could cause damage to the network.
Access Privilege Levels Overview
Each top-level CLI command and configuration statement has an associated access privilege level. Users can execute only those commands and configure and view only those statements for which they have access privileges. One or more permission flags define the access privileges for each login class.
For each login class, you can also explicitly allow or deny the use of operational mode and
configuration mode commands and statement hierarchies that would otherwise be allowed or
denied by a privilege level specified in the permissions
statement.
- Login Class Permission Flags
- Allow and Deny Individual Commands and Statement Hierarchies for Login Classes
Login Class Permission Flags
You use permission flags to grant a user access to operational mode commands and
configuration hierarchy levels and statements. You configure permission flags for
the user's login class at the [edit system login class]
hierarchy
level. When you specify a certain permission flag, the user gains access to the
commands and to the configuration hierarchy levels and statements that correspond to
that flag. To grant access to all commands and configuration statements, use the
all
permissions flag.
Each command listed represents that command and all subcommands with that command as a prefix. Each configuration statement listed represents the top of the configuration hierarchy to which that flag grants access.
The permissions
statement specifies one or more of the permission
flags listed in Table 1.
Permission flags are not cumulative. For each class you must list all the permission
flags needed, including view
to display information and
configure
to enter configuration mode. Two forms of permissions
control a user's access to the individual parts of the configuration:
-
"Plain” form—Provides read-only capability for that permission type. An example is
interface
. -
-control
form—Provides read and write capability for that permission type. An example isinterface-control
.
For permission flags that grant access to configuration hierarchy levels and
statements, the plain form flags grant read-only privilege to that configuration.
For example, the interface
permission flag grants read-only access
to the [edit interfaces]
hierarchy level. The
-control
form of the flag grants read-write access to that
configuration. For example, the interface-control
flag grants
read-write access to the [edit interfaces]
hierarchy level.
Table 1 lists
the login class permission flags that you can configure by including the
permissions
statement at the [edit system login class
class-name]
hierarchy level.
The permission flags grant a specific set of access privileges. Each permission flag is listed with the operational mode or configuration mode commands and configuration hierarchy levels and statements for which that flag grants access.
Permission Flag |
Description |
---|---|
|
Can view the access configuration in operational mode or configuration mode. |
|
Can view and configure access information at the |
|
Can view user account information in operational mode or configuration mode. |
|
Can view user account information and configure it at the
|
|
Can access all operational mode commands and configuration mode commands. Can modify the configuration in all the configuration hierarchy levels. |
|
Can clear (delete) information that the device learns from the
network and stores in various network databases (using the
|
|
Can enter configuration mode (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 operational mode or 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 operational mode or configuration mode. |
|
Can view and configure flow-tap 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 operational mode and configuration mode. |
|
Can view chassis, class of service (CoS), groups, forwarding options, and interfaces configuration information. Can modify the configuration at the following hierarchy levels:
|
|
Can perform system maintenance, including starting a local shell
on the device and becoming the superuser in the shell (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 mode and operational mode. |
|
Can view and configure general routing at the |
|
Can view passwords and other authentication keys in the configuration. |
|
Can view and modify passwords and other authentication keys in the configuration. |
|
Can view security configuration information in operational mode and configuration mode. |
|
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 operational mode or configuration mode. |
|
Can view and modify SNMP configuration information at the
|
|
Can view Fiber Channel storage configuration information at the
|
|
Can modify Fiber Channel storage configuration information at the
|
|
Can view system-level information in operational mode or configuration mode. |
|
Can view and modify system-level configuration information at the
|
|
Can view trace file settings and configure trace file properties. |
|
Can modify trace file settings and configure trace file properties. |
|
Can view unified edge configuration at the |
|
Can modify unified edge related configuration at the
|
|
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 |
Allow and Deny Individual Commands and Statement Hierarchies for Login Classes
By default, all top-level CLI commands and configuration hierarchy levels have
associated access privilege levels. Users can execute only those commands and view
and configure only those statements for which they have access privileges. For each
login class, you can explicitly allow and deny the use of operational mode and
configuration mode commands and statement hierarchies that would otherwise be
allowed or denied by a privilege level specified in the permissions
statement.
Permission flags grant a user access to operational mode and configuration mode
commands and to configuration hierarchy levels and statements. By specifying a
specific permission flag on the user's login class at the [edit system login
class]
hierarchy level, you grant the user access to the corresponding
commands and configuration hierarchy levels and statements. To grant access to all
commands and configuration statements, use the all
permissions
flag.
You can explicitly allow or deny the use of commands and statements by configuring
the allow-commands
, deny-commands
,
allow-configuration
, and deny-configuration
statements for a login class. In the statements, you use extended regular
expressions to define which commands and statements to allow or deny for users
assigned to the class.
Example: Configure User Permissions with Access Privilege Levels
This example configures the user permissions for a login class. You configure user permissions for a login class to prevent users from performing unauthorized network actions. Users can execute only those commands and view and modify only those statements for which they have access privileges. This constraint prevents unauthorized users from executing sensitive commands or configuring statements that could cause damage to the network.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
Each top-level CLI command and each configuration statement has an access privilege level associated with it. When you configure a login class, you can explicitly allow or deny the use of operational mode and configuration mode commands and configuration statements. Users can execute only those commands and view and configure only those statements for which they have access privileges.
You define the access privileges for each login class by specifying one or more permission
flags in the permissions
statement. Permission flags grant a user access to
commands, statements, and hierarchies. Permission flags are not cumulative. For each login
class you must list all the permission flags needed, including view
to
display information and configure
to enter configuration mode. By
specifying a specific permission flag on the user's login class, you grant the user access
to the corresponding commands, statements, and hierarchies. To grant access to all commands
and configuration statements, use the all
permissions flag. The permission
flags provide read-only (“plain” form) and read and write (form that ends in -control)
capability for a permission type.
The all
login class permission bits take precedence over extended
regular expressions when a user issues a rollback
command with the
rollback
permission flag enabled.
To configure user access privilege levels for a login class, include the
permissions
statement at the [edit system login class
class-name]
hierarchy level, followed by the permission
flags. Configure multiple permissions as a space-separated list enclosed in square
brackets:
[edit system login] user@host# set class class-name permissions permission-flag user@host# set class class-name permissions [flag1 flag2 flag3]
To view the available permissions, use the CLI's context-sensitive help and type a
question mark (?) after the permissions
statement:
[edit system login] user@host# set class class-name permissions ?
Configuration
This example configures the snmp-admin
login class. Users in this login
class can configure and view SNMP parameters only.
Configure User Permissions with Access Privilege Levels
Step-by-Step Procedure
To configure access privileges for the login class:
-
Configure the
snmp-admin
login class with theconfigure
,snmp
, andsnmp-control
permission flags.[edit system login] user@host# set class snmp-admin permissions [configure snmp snmp-control]
The configured permission flags provide both read (snmp) and read-and-write (snmp-control) capability for SNMP, and this is the only allowed access privilege for this login class. All other access privileges are denied.
-
Create the user accounts that are assigned to the
snmp-admin
login class.[edit system login] user@host# set user snmpuser class snmp-admin authentication plain-text-password New password: Retype new password:
Results
In configuration mode, confirm your configuration by entering the show system
login
command. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
user@host# show system login class snmp-admin { permissions [ configure snmp snmp-control ]; } user snmpuser { class snmp-admin; authentication { encrypted-password "$ABC123"; ## SECRET-DATA } }
After configuring the device, enter commit
in configuration mode.
Verification
Log in using a username assigned to the new login class, and confirm that the configuration is working properly.
Verify SNMP Configuration
Purpose
Verify that a user in the snmp-admin
login class can configure SNMP.
Action
In configuration mode, configure SNMP statements at the [edit snmp]
hierarchy
level.
[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 in the snmp-admin
login class is able to configure SNMP parameters.
The user can configure these parameters because the permission flags specified for this
class include both snmp (read capabilities) and snmp-control (read and write
capabilities) permission bits.
Verify non-SNMP Configuration
Purpose
Verify that a user in the snmp-admin
login class cannot modify
non-SNMP configuration statements.
Action
In configuration mode, attempt to configure any non-SNMP statement, such as a statement
in the interfaces
hierarchy.
[edit] user@host# edit interfaces Syntax error, expecting <statement> or <identifier>.
Meaning
The user in the snmp-admin
login class is not able to configure the
[edit interfaces]
hierarchy because the permission flags specified
for this class do not allow it. In this case, the CLI issues an error message.
Regular Expressions to Allow and Deny Operational Mode Commands, Configuration Statements, and Hierarchies
This topic contains the following sections:
- Understanding the Allow and Deny Statements
- Understanding the Allow and Deny Statement Syntax
- Understanding the Allow and Deny Statement Precedence and Matching
- Understanding the Allow and Deny Statement Rules
- Understanding Differences for the *-regexps Statements
- Using Regular Expressions on Remote Authorization Servers
- Specify Regular Expressions
- Regular Expressions Operators
- Regular Expression Examples
Understanding the Allow and Deny Statements
Each top-level CLI command and configuration statement hierarchy has an access privilege level associated with it. Each login class can explicitly allow or deny the use of operational mode and configuration mode commands and configuration hierarchies and statements that would otherwise be allowed or denied by a privilege level. Users can execute only those commands and view and configure only those statements for which they have access privileges.
The access privileges for each login class are defined by one or more permission
flags specified in the permissions
statement at the [edit
system login class class-name]
hierarchy level. In
addition, you can allow or deny the use of specific commands and configuration
hierarchies by defining extended regular expressions. You can specify the regular
expressions by configuring the following statements for a login class:
-
allow-commands
anddeny-commands
—Allow or deny access to operational mode and configuration mode commands. -
allow-configuration
anddeny-configuration
—Allow or deny access to specific configuration hierarchies.Note:These statements perform slower matching, with more flexibility, especially in wildcard matching. However, it can take a very long time to evaluate all of the possible statements if a great number of full-path regular expressions or wildcard expressions are configured, possibly negatively affecting performance.
-
allow-commands-regexps
anddeny-commands-regexps
—Allow or deny access to particular commands using strings of regular expressions. -
allow-configuration-regexps
anddeny-configuration-regexps
—Allow or deny access to specific configuration hierarchies using strings of regular expressions.
If your existing configurations use the allow/deny-commands
or
allow/deny-configuration
statements, using the same
configuration options with the allow/deny-commands-regexps
or
allow/deny-configuration-regexps
statements might not
produce the same results. The search and match methods differ in the two forms
of these statements.
Explicitly allowing commands and configuration statement hierarchies using the
allow/deny-*
statements adds to the permissions that the
permissions
statement already defines. Likewise, explicitly
denying commands and configuration statement hierarchies using the
allow/deny-*
statements removes permissions that the
permissions
statement already defines.
For example, in the following configuration, the configure
permission enables users in the login class to enter configuration mode.
Additionally, the allow-configuration
expression allows users to
modify the configuration at the [edit system services]
hierarchy
level and commit it.
[edit system login class test] user@host# set permissions configure allow-configuration "system services"
Similarly, in the following configuration, the login class user can perform all
operations that the all
permissions flag allows, except that the
user cannot view or modify the configuration at the [edit system
services]
hierarchy level:
[edit system login class test] user@host# set permissions all deny-configuration "system services"
Understanding the Allow and Deny Statement Syntax
You can configure an allow/deny-*
statement only once in each login
class. When you configure a statement:
-
You can configure as many regular expressions as needed.
-
Regular expressions are not case-sensitive
The allow/deny-commands
statements are mutually exclusive with the
allow/deny-commands-regexps
statements, and the
allow/deny-configuration
statements are mutually exclusive with
the allow/deny-configuration-regexps
statements. For example, you
cannot configure both allow-configuration
and
allow-configuration-regexps
in the same login class.
To define access privileges to commands, specify extended regular expressions using
the allow-commands
and deny-commands
statements.
Enclose each complete standalone expression in parentheses ( ), and use the pipe
( | ) symbol to separate the expressions. Do not use spaces between regular
expressions that are connected with the pipe symbol. The complete expression is
enclosed in double quotation marks.
allow-commands "(cmd1)|(cmd2)|(cmdn)" allow-configuration "(config1)|(config2)|(confign)"
For example:
[edit system login class test] user@host# set allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"
You must use anchors when specifying complex regular expressions with the
allow-commands
statement. For example:
[edit system login] user@host# set class test allow-commands "(^monitor)|(^ping)|(^show)|(^exit)"
To define access privileges to parts of the configuration hierarchy, specify extended
regular expressions in the allow-configuration
and
deny-configuration
statements. Enclose the full paths in
parentheses ( ), and use the pipe ( | ) symbol to separate the expressions. Do not
use spaces between regular expressions that are connected with the pipe symbol. The
complete expression is enclosed in double quotation marks.
allow-configuration "(config1)|(config2)|(confign)"
For example:
[edit system login class test] user@host# set deny-configuration "(system login class)|(system services)"
When specifying extended regular expressions using the
allow/deny-commands-regexps
or
allow/deny-configuration-regexps
statements, enclose each
expression within quotation marks (" "), and separate the expressions using a space.
Enclose multiple expressions in square brackets [ ]. For example:
[edit system login class test] user@host# set allow-configuration-regexps ["interfaces .* description .*" "interfaces .* unit .* description .*" “interfaces .* unit .* family inet address .*" "interfaces.* disable"]
Modifiers such as set
, log
, and
count
are not supported within the regular expression string to
be matched. If you use a modifier, then nothing is matched.
Correct configuration:
[edit system login class test] user@host# set deny-commands protocols
Incorrect configuration:
[edit system login class test] user@host# set deny-commands "set protocols"
Understanding the Allow and Deny Statement Precedence and Matching
By default, the allow-commands
and
allow-configuration
regular expressions take precedence over
deny-commands
and deny-configuration
expresssions. Thus, if you configure the same command for both the
allow-commands
and deny-commands
statements,
then the allow operation takes precedence over the deny operation. Similarly, if you
configure the same statement for both the allow-configuration
and
deny-configuration
statements, then the allow operation takes
precedence over the deny operation.
For instance, the following configuration allows a user in the test
login class to install software using the request system software
add
command, even though the deny-commands
statement
includes the same command:
[edit system login class test] user@host# set allow-commands "request system software add" user@host# set deny-commands "request system software add"
Similarly, the following configuration allows a user in the test
login class test to view and modify the [edit system services]
configuration hierarchy, even though the deny-configuration
statement includes the same hierarchy:
[edit system login class test] user@host# set allow-configuration "system services" user@host# set deny-configuration "system services"
If the allow-commands
and deny-commands
statements
have two different variants of a command, the longest match is always executed. The
following configuration allows a user in the test
login class to
execute the commit synchronize
command but not the
commit
command. This is because commit
synchronize
is the longest match between commit
and
commit synchronize
, and it is specified for
allow-commands
.
[edit system login class test] user@host# set allow-commands "commit synchronize" user@host# set deny-commands commit
The following configuration allows a user in the test
login class to
execute the commit
command but not the commit
synchronize
command. This is because commit
synchronize
is the longest match between commit
and
commit synchronize
, and it is specified for
deny-commands
.
[edit system login class test] user@host# set allow-commands commit user@host# set deny-commands "commit synchronize"
In contrast to the other statements, the default behavior for the
*-regexps
statements is that the
deny-commands-regexps
and
deny-configuration-regexps
regular expressions take precedence
over allow-commands-regexps
and
allow-configuration-regexps
expressions. You can configure the
regex-additive-logic
statement at the [edit
system]
hierarchy level to force the
allow-configuration-regexps
regular expressions to take
precedence over the the deny-configuration-regexps
statements.
Configuring the statement enables you to deny configuration hierarchies at a higher
level and then only allow the user access to specific sub-hierarchies.
Understanding the Allow and Deny Statement Rules
The allow/deny-commands
, allow/deny-configuration
,
allow/deny-commands-regexps
, and
allow/deny-configuration-regexps
statements take precedence
over the login class permissions. When you configure these statements, the following
rules apply:
-
Regular expressions for
allow-commands
anddeny-commands
statements can also include thecommit
,load
,rollback
,save
,status
, andupdate
commands. -
The
all
login class permission bits take precedence over extended regular expressions when a user issues therollback
command with therollback
permission flag enabled. -
Users cannot issue the
load override
command when specifying an extended regular expression. Users can only issue themerge
,replace
, andpatch
configuration commands. -
You can use the * wildcard character when denoting regular expressions. However, you must use it as part of a regular expression. You cannot use
[ * ]
or[ .* ]
as the only expression. Additionally, you cannot configure theallow-configuration
statement with an expression such as(interfaces (description (|.*))
, because this evaluates toallow-configuration .*
.
Understanding Differences for the *-regexps Statements
This section outlines the differences between the
allow/deny-configuration
statements and the
allow/deny-configuration-regexps
statements.
The allow/deny-configuration-regexps
statements split up the regular
expression into tokens and match each piece against each part of the specified
configuration’s full path, whereas the allow/deny-configuration
statements match against the full string. For
allow/deny-configuration-regexps
statements, you configure a
set of strings in which each string is a regular expression, with spaces between the
terms of the string. This syntax provides very fast matching but offers less
flexibility. For specifying wildcard expressions, you must set up wildcards for each
token of the space-delimited string you want to match, which makes it more difficult
to use wildcard expressions for these statements.
For example:
-
Regular expression matching one token using allow-configuration-regexps
This example shows that
options
is the only matched expression against the first token of the statement.[edit system] login { class test { permissions configure; allow-configuration-regexps .*options; } }
The preceding configuration matches the following statements:
-
set policy-options condition condition dynamic-db
-
set routing-options static route static-route next-hop next-hop
-
set event-options generate-event event time-interval seconds
The preceding configuration does not match the following statements:
-
system host-name host-options
-
interfaces interface-name description options
-
-
Regular expression matching three tokens using allow-configuration-regexps
This example shows that
ssh
is the only matched expression against the third token of the statement.[edit system] login { class test { permissions configure; allow-configuration-regexps ".* .* .*ssh"; } }
In the preceding example, the three tokens include
.*
,.*
, and.*ssh
, respectively.The preceding configuration matches the following statements:
-
system host-name hostname-ssh
-
system services ssh
-
system services outbound-ssh
The preceding configuration does not match the following statement:
-
interfaces interface-name description ssh
-
It is easier to use the deny-configuration
statement to restrict
configuration access than to use the deny-configuration-regexps
statement. Table 2 illustrates the use of both the
deny-configuration
and
deny-configuration-regexps
statements in different
configurations to achieve the same result of restricting access to a particular
configuration.
Configuration Denied |
Using: |
Using: |
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 you want a simple configuration, the
allow/deny-configuration-regexps
statements provide better
performance and overcome the ambiguity that existed when combining expressions in
the allow/deny-configuration
statements.
Using Regular Expressions on Remote Authorization Servers
You can use extended regular expressions to specify which operational mode and
configuration mode commands and configuration statements and hierarchies are allowed
or denied for certain users. You specify these regular expressions locally in the
allow/deny-commands
, allow/deny-configuration
,
allow/deny-commands-regexps
and
allow/deny-configuration-regexps
statements at the
[edit system login class class-name]
hierarchy level. You specify these regular expressions remotely by specifying
Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your authorization
server’s configuration. When you configure authorization parameters both locally and
remotely, the device merges the regular expressions received during TACACS+ or
RADIUS authorization with any regular expressions defined on the local device.
When specifying multiple regular expressions in a local configuration using the
allow-commands
, deny-commands
,
allow-configuration
, or deny-configuration
statements, you configure regular expressions within parentheses and separate them
using the pipe symbol. You enclose the complete expression in double quotation
marks. For example, you can specify multiple allow-commands
parameters with the following syntax:
allow-commands "(cmd1)|(cmd2)|(cmdn)"
The RADIUS authorization server uses the following attributes and syntax:
Juniper-Allow-Commands += "(cmd1)|(cmd2)|(cmd3)", Juniper-Deny-Commands += "(cmd1)|(cmd2)", Juniper-Allow-Configuration += "(config1)|(config2)", Juniper-Deny-Configuration += "(config1)|(config2)",
The TACACS+ authorization server uses the following attributes and syntax:
allow-commands = "(cmd1)|(cmd2)|(cmdn)" deny-commands = "(cmd1)|(cmd2)|(cmdn)" allow-configuration = "(config1)|(config2)|(confign)" deny-configuration = "(config1)|(config2)|(confign)"
When specifying multiple regular expressions in a local configuration using the
allow-commands-regexps
, deny-commands-regexps
,
allow-configuration-regexps
, or
deny-configuration-regexps
statements, you configure regular
expressions within double quotation marks and separate them using the space
operator. You enclose the complete expression in square brackets. For example, you
can specify multiple allow-commands parameters with the following syntax:
allow-commands-regexps [ "cmd1" "cmd2" "cmdn" ]
The RADIUS authorization server uses the following attributes and syntax:
Juniper-Allow-Configuration-Regexps += "(config1)|(config2)|(confign)", Juniper-Deny-Configuration-Regexps += "(config1)|(config2)|(confign)",
The TACACS+ authorization server uses the following attributes and syntax:
allow-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" deny-commands-regexps = "(cmd1)|(cmd2)|(cmdn)" allow-configuration-regexps = "(config1)|(config2)|(confign)" deny-configuration-regexps = "(config1)|(config2)|(confign)"
RADIUS and TACACS+ servers also support a simplified syntax where you specify each individual expression on a separate line. For example, the RADIUS server simplified syntax is:
Juniper-Allow-Commands += "cmd1", Juniper-Allow-Commands += "cmd2", Juniper-Allow-Commands += "cmdn",
Similarly, the TACACS+ server simplified syntax is:
allow-commands-regexps1 = "cmd1" allow-commands-regexps2 = "cmd2" allow-commands-regexpsn = "cmdn"
Table 3 differentiates the local authorization configuration and the TACACS+ server authorization configuration using regular expressions.
Local Configuration |
Remote TACACS+ Configuration |
---|---|
login { class local { permissions configure; allow-commands "(ping .*)|(traceroute .*)|(show .*)|(configure .*)|(edit)|(exit)|(commit)|(rollback .*)"; deny-commands .*; allow-configuration "(interfaces .* unit 0 family ethernet-switching vlan mem.* .*)|(interfaces .* native.* .*)|(interfaces .* unit 0 family ethernet-switching interface-mo.* .*)|(interfaces .* unit .*)|(interfaces .* disable)|(interfaces .* description .*)|(vlans .* vlan-.* .*)" deny-configuration .*; } } |
user = remote { login = username service = junos-exec { allow-commands1 = "ping .*" allow-commands2 = "traceroute .*" allow-commands3 = "show .*" allow-commands4 = "configure" allow-commands5 = "edit" allow-commands6 = "exit" allow-commands7 = "commit" allow-commands8 = ".*xml-mode" allow-commands9 = ".*netconf.*" allow-commands10 = ".*need-trailer" allow-commands11 = "rollback.*" allow-commands12 = "junoscript" deny-commands1 = ".*" allow-configuration1 = "interfaces .* unit 0 family ethernet-switching vlan mem.* .*" allow-configuration2 = "interfaces .* native.* .*" allow-configuration3 = "interfaces .* unit 0 family ethernet-switching interface-mo.* .*" allow-configuration4 = "interfaces .* unit .*" allow-configuration5 = "interfaces .* disable" allow-configuration6 = "interfaces .* description .*" allow-configuration7 = "interfaces .*" allow-configuration8 = "vlans .* vlan-.* .*" deny-configuration1 = ".*" local-user-name = local-username user-permissions = "configure" } } |
-
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 you use the
deny-configuration = ".*"
statement, you must allow all the desired configurations using theallow-configuration
statement. However, this configuration can affect the allowed regular expressions buffer limit for theallow-configuration
statement. If this limit is exceeded, the allowed configuration might not work.
Specify Regular Expressions
When you specify regular expressions for commands and configuration statements, pay close attention to the following examples. A regular expression with invalid syntax might not produce the desired results, even if the configuration is committed without any error.
You should specify regular expressions for commands and configuration statements in
the same manner as executing the complete command or statement. Table 4 lists the regular expressions for configuring access privileges for the
[edit interfaces]
and [edit vlans]
statement
hierarchies.
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 .*" |
|
[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 5 lists common regular expression operators that you can use for allowing or denying operational and configuration modes.
Command regular expressions implement the extended (modern) regular expressions, as defined in POSIX 1003.2.
Operator |
Match |
Example |
---|---|---|
| |
One of two or more terms separated by the pipe. Each term must be a complete standalone expression enclosed in parentheses ( ), with no spaces between the pipe and the adjacent parentheses. |
[edit system login class test] user@host# set permissions configure user@host# set allow-commands "(ping)|(traceroute)|(show system alarms)|(show system software)" user@host# set deny-configuration "(access)|(access-profile)|(accounting-options)|(applications)|(apply-groups)|(bridge-domains)|(chassis)|(class-of-service)" With the preceding configuration, the users assigned to the test
login class have operational mode access restricted to only the
commands specified in the |
^ |
At the beginning of an expression, used to denote where the command begins, where there might be some ambiguity. |
[edit system login class test] user@host# set permissions interface user@host# set permissions interface-control user@host# set allow-commands "(^show) (log|interfaces|policer))|(^monitor)" With the preceding configuration, the users assigned to the test
login class have access to viewing and configuring the interface
configuration. The 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 preceding configuration, the users assigned to the test
login class can view the interfaces configuration in
configuration mode. The users can also view the interface
configuration with the |
[ ] |
Range of letters or digits. To separate the start and end of a
range, use a hyphen ( - |
[edit system login class test] user@host# set permissions clear user@host# set permissions configure user@host# set permissions network user@host# set permissions trace user@host# set permissions view user@host# set allow-configuration-regexps [ "interfaces [gx]e-.* unit [0-9]* description .*" ] With the preceding configuration, the users assigned to the test login class have operator-level user permissions. These users also have access to configure interfaces within the specified range of interface name and unit number (0 through 9). |
( ) |
A group of commands indicating a complete, standalone expression to be evaluated. The result is then evaluated as part of the overall expression. Parentheses must be used in conjunction with pipe operators, as explained. |
[edit system login class test] user@host# set permissions all user@host# set allow-commands "(clear)|(configure)" user@host# deny-commands "(mtrace)|(start)|(delete)" With the above configuration, users assigned to the test login
class have superuser-level permissions and have access to the
commands specified in the |
* |
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:
|
The !
regular expression operator is not supported.
Regular Expression Examples
Table 6 lists the regular expressions used to allow configuration options under two
configuration hierarchies—[edit system ntp server]
and
[edit protocols rip]
—as an example for specifying regular
expressions.
Table 6 does not provide a comprehensive list of all regular expressions and keywords
for all configuration statements and hierarchies. The regular expressions listed
in the table are validated only for the [edit system ntp
server]
and [edit protocols rip]
statement
hierarchies.
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 .*" ] |
|
|
How to Define Access Privileges with allow-configuration and deny-configuration Statements
You can define access privileges for configuration statement hierarchies by using a combination of the following types of statements:
permission flags
allow-configuration
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 contain one or more regular
expressions that allow or deny specific configuration hierarchies and statements. The
allow-configuration
and deny-configuration
statements take precedence over permission flags and give the administrator finer
control over exactly what hierarchies and statements the user can view and configure.
This topic explains how to define access privileges using allow-configuration
and deny-configuration
statements by showing examples of login class
configurations that use these statements. Examples 1 through 3 create login classes that
allow users access to all commands and statements except those defined in the
deny-configuration
statement.
Notice that permission bit and permission flag are used interchangeably.
Example 1
To create a login class that allows the user to execute all commands and configure everything except telnet parameters:
Example 2
To create a login class that allows the user to execute all commands and configure everything except statements within any login class whose name begins with “m”:
-
Set the user’s login class permissions 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
To create a login class that allows the user to execute all commands and configure
everything except the [edit system login class]
or [edit
system services]
hierarchy levels:
-
Set the user’s login class permissions 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 following examples show how to use the allow-configuration
and
deny-configuration
statements to determine permissions inverse
to each other for the [edit system services]
hierarchy level.
Example 4
To create a login class that allows the user to have full configuration privileges
only at the [edit system services]
hierarchy level:
-
Set the user’s login class permissions 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 commands and
all configuration hierarchies except the [edit system services]
hierarchy level:
-
Set the user’s login class permissions 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: Use Additive Logic with Regular Expressions to Specify Access Privileges
This example shows how to use additive logic when using regular expressions to set up configuration access privileges.
Requirements
No special configuration beyond device initialization is required before configuring this example.
Overview
You can define regular expressions to control who can make changes to the
configuration and what they can change. These regular expressions indicate specific
configuration hierarchies that users in a login class are permitted to access. For
example, you can define regular expressions that allow users to modify a group of
routing instances and define regular expressions that prevent the users from making
changes to any other routing instances or to other configuration levels. You define
the regular expressions by configuring the
allow-configuration-regexps
and
deny-configuration-regexps
statements for a login class.
By default, the deny-configuration-regexps
statement takes
precedence over the allow-configuration-regexps
statement. If a
configuration hierarchy appears in a deny-configuration-regexps
statement for a login class, it is not visible to the users in that class,
regardless of the contents of the allow-configuration-regexps
statement. If a configuration hierarchy does not appear in a
deny-configuration-regexps
statement, it is visible to the
users in that class if it appears in an allow-configuration-regexps
statement.
You can change this default behavior by enabling additive logic for the
*-configuration-regexps
statements. When you enable additive
logic, the allow-configuration-regexps
statement takes precedence
over the deny-configuration-regexps
statement.
Thus, if the deny-configuration-regexps
statement denies access to
all configuration hierarchies at a given level (protocols .*) but the
allow-configuration-regexps
statement allows access to one
sub-hierarchy (protocols bgp .*), then by default the device denies access to the
hierarchies for users in that login class because the
deny-configuration-regexps
statement takes precedence. However,
if you enable additive logic, the device allows access to the specified
sub-hierarchy for users in that login class because the
allow-configuration-regexps
takes precedence in this case.
Configuration
Step-by-Step Procedure
To enable additive logic to explicitly allow users in a given login class access to one or more individual configuration hierarchies:
-
Include the
deny-configuration-regexps
statement, and explicitly deny access to configuration hierarchies.[edit system login class class-name] user@host# set deny-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
For example:
[edit system login class class-name] user@host# set deny-configuration-regexps "protocols .*"
-
Include the
allow-configuration-regexps
statement, and define regular expressions for the specific hierarchies to allow.[edit system login class class-name] user@host# set allow-configuration-regexps ["regular expression 1" "regular expression 2" "regular expression 3"]
For example:
[edit system login class class-name] user@host# set allow-configuration-regexps ["protocols bgp .*" "protocols ospf .*"]
-
Enable additive logic for the
allow-configuration-regexps
anddeny-configuration-regexps
regular expressions.[edit system] user@host# set regex-additive-logic
-
Assign the login class to one or more users.
[edit system login] user@host# set user username class class-name
-
Commit your changes.
Users assigned to this login class have access to the configuration hierarchies included in the
allow-configuration-regexps
statement but do not have access to the other hierarchies specified in thedeny-configuration-regexps
statement.
When you configure the regex-additive-logic
statement, the
behavior change applies to all allow-configuration-regexps
and deny-configuration-regexps
statements present in all
login classes. If you enable additive logic, you should evaluate existing
statements for any impact, and update the regular expressions in those
statements as appropriate.
Examples
Use Regular Expressions with Additive Logic
Purpose
This section provides examples of regular expressions that use additive logic to give you ideas for creating configurations appropriate for your system.
Allow Specific Routing Instances
The following example login class includes a regular expression that allows
configuration of routing instances whose names start with
CUST-VRF-
; for example, CUST-VRF-1
,
CUST-VRF-25
, CUST-VRF-100
, and so on.
The example also includes a regular expression that prevents the
configuration of any routing instances.
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "routing-instances .*" user@host# set allow-configuration-regexps "routing-instances CUST-VRF-.* .*"
By default, the deny-configuration-regexps
statement takes
precedence, and the previous configuration prevents the users in the login
class from configuring any routing instances, regardless of the name.
However if you configure the following statement, the
allow-configuration-regexps
statement takes precedence.
Thus, the users can configure routing instances whose names start with
CUST-VRF-
, but the users cannot configure any other
routing instances.
[edit system] user@host# set regex-additive-logic
Allow BGP Peer Configuration Only
The following example login class includes regular expressions that prevent
configuration at the [edit protocols]
hierarchy level but
allow configuration of BGP peers:
[edit system login class class-name] user@host# set permissions [configure routing-control view view-configuration] user@host# set deny-configuration-regexps "protocols .*" user@host# set allow-configuration-regexps "protocols bgp group *"
By default, the previous configuration prevents the users in the login class
from making changes to any hierarchies under [edit
protocols]
.
However, if you configure the following statement, the users in the login class can make changes to BGP peers, but the users cannot configure other protocols or other BGP statements outside of the allowed hierarchy level.
[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 configure the hierarchy levels that are allowed.
-
You should be able to configure statements in hierarchy levels that have been allowed.
-
Hierarchy levels that are denied should not be visible.
-
Any allowed or denied expressions should take precedence over any permissions granted with the
permissions
statement.
-
Example: Configure User Permissions with Access Privileges for Operational Mode Commands
This example shows how to configure custom login classes and assign access privileges for operational mode commands. Users in the login class can execute only the commands for which they have access. This prevents unauthorized users from executing sensitive commands that could cause damage to the network.
Requirements
This example uses the following hardware and software components:
-
One Juniper Networks device
-
One TACACS+ (or RADIUS) server
Before you begin, establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS server, establish a UDP connection between the device and the RADIUS server.
Overview and Topology
Figure 1 illustrates a simple topology, where Router R1 is a Juniper Networks device and has a TCP connection established with a TACACS+ server.
This example configures R1 with three customized login classes: Class1, Class2, and
Class3. Each class defines access privileges for the user by configuring the
permissions
statement and by defining extended regular
expressions using the allow-commands
and
deny-commands
statements.
The purpose of each login class is as follows:
-
Class1—Defines access privileges for the user with the
allow-commands
statement only. This login class provides operator-level user permissions and authorization for rebooting the device. -
Class2—Defines access privileges for the user with the
deny-commands
statement only. This login class provides operator-level user permissions and denies access 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 authorization for accessing interfaces and viewing device information. It also denies access to theedit
andconfigure
commands.
Router R1 has three different users, User1, User2, and User3 assigned to the Class1, Class2, and Class3 login classes, respectively .
Configuration
- CLI Quick Configuration
- Configure Authentication Parameters for Router R1
- Configure Access Privileges with the allow-commands Statement (Class1)
- Configure Access Privileges with the deny-commands Statement (Class2)
- Configure Access Privileges with Both the 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
in 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 secret "$ABC123" 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 destination tacplus server 10.209.1.66 secret "$ABC123" 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
Configure Authentication Parameters for Router R1
Step-by-Step Procedure
To configure Router R1 authentication:
-
Configure the order in which R1 attempts to authenticate the user. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, and then the local password.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Configure the TACACS+ server.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Configure the RADIUS server.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Configure R1 accounting parameters.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands
Configure Access Privileges with the allow-commands Statement (Class1)
Step-by-Step Procedure
To specify regular expressions using the allow-commands
statement:
-
Configure the Class1 login class and assign operator-level user permissions.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configure the
allow-commands
regular expression to enable users in the class to reboot the device.[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"
Configure Access Privileges with the deny-commands Statement (Class2)
Step-by-Step Procedure
To specify regular expressions using the deny-commands
statement:
-
Configure the Class2 login class and assign operator-level user permissions.
[edit system login] user@R1# set class Class1 permissions [clear network reset trace view]
-
Configure the
deny-commands
regular expression to prevent users in the class from executingset
commands.[edit system login] user@R1# set class Class1 deny-commands "set"
-
Configure the user account for the Class2 login class.
[edit system login] user@R1# set user User2 uid 2002 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Configure Access Privileges with Both the allow-commands and deny-commands Statements (Class3)
Step-by-Step Procedure
To specify regular expressions using both the allow-commands
and deny-commands
statements:
-
Configure the Class3 login class and assign superuser-level permissions.
[edit system login] user@R1# set class Class3 permissions all
-
Configure the
deny-commands
regular expression to prevent users in the class from executing any commands.[edit system login] user@R1# set class Class3 deny-commands ".*"
-
Configure the
allow-commands
regular expression to allow users to enter configuration mode.[edit system login] user@R1# set class Class3 allow-commands configure
-
Configure the user account for the Class3 login class.
[edit system login] user@R1# set user User3 uid 2003 user@R1# set user User3 class Class3 user@R1# set user User3 authentication encrypted-password "$ABC123"
Results
In configuration mode, confirm your configuration by entering the show
system
command. If the output does not display the intended
configuration, repeat the instructions in this example to correct the
configuration.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } 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 the Class1 Configuration
- Verifying the Class2 Configuration
- Verifying Class3 Configuration
Verifying the Class1 Configuration
Purpose
Verify that the permissions and commands allowed in the Class1 login class are working.
Action
In operational mode, run the show system users
command.
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)
In 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 operator-level user permissions and allows
users in the class to execute the request system reboot
command.
The predefined operator login class has the following permission flags specified:
clear—Can use
clear
commands to clear (delete) information that the device learns from the network and stores in various network databases.network—Can access the network by using the
ping
,ssh
,telnet
, andtraceroute
commands.reset—Can restart software processes by using the
restart
command.trace—Can view trace file settings and configure trace file properties.
view—Can use various commands to display current system-wide, routing table, and protocol-specific values and statistics. Cannot view the secret configuration.
For the Class1 login class, in addition to the above-mentioned user permissions, User1 can
execute the request system reboot
command. The first output
displays the view permissions as an operator, and the second output shows
that the only request system
command that User1 can execute
as an operator is the request system reboot
command.
Verifying the Class2 Configuration
Purpose
Verify that the permissions and commands allowed for the Class2 login class are working.
Action
In operational mode, run the ping
command.
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 commands.
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 operator-level user permissions and denies
access to all set
commands.
The permission flags specified for the predefined operator login class are the same as those specified for Class1.
Verifying Class3 Configuration
Purpose
Verify that the permissions and commands allowed for the Class3 login class are working.
Action
In operational mode, check the available commands.
User3@R1> ? Possible completions: configure Manipulate software configuration information
Enter configuration mode.
User3@R1> configure Entering configuration mode [edit] User3@R1#
Meaning
The Class3 login class to which User3 is assigned has superuser (all) permissions, but this class
only allows users to execute the configure
command. The
class denies access to all other operational mode commands. Because the
regular expressions specified in the allow/deny-commands
statements take precedence over the user permissions, User3 on R1 has access
only to configuration mode and is denied access to all other operational
mode commands.
Example: Configure User Permissions with Access Privileges for Configuration Statements and Hierarchies
This example shows how to configure custom login classes and assign access privileges to specific configuration hierarchies. Users in the login class can view and modify only those configuration statements and hierarchies to which they have access. This prevents unauthorized users from modifying device configurations that could cause damage to the network.
Requirements
This example uses the following hardware and software components:
-
One Juniper Networks device
-
One TACACS+ (or RADIUS) server
Before you begin, establish a TCP connection between the device and the TACACS+ server. In the case of the RADIUS server, establish a UDP connection between the device and the RADIUS server.
Overview and Topology
Figure 2 illustrates a simple topology, where Router R1 is a Juniper Networks device and has a TCP connection established with a TACACS+ server.
This example configures R1 with two customized login classes: Class1 and Class2. Each
class defines access privileges for the user by configuring the
permissions
statement and by defining extended regular
expressions using the allow-configuration
,
deny-configuration
,
allow-configuration-regexps
, and
deny-configuration-regexps
statements.
The purpose of each login class is as follows:
-
Class1—Defines access privileges for the user with the
allow-configuration
anddeny-configuration
statements. This login class provides access to configure the[edit interfaces]
hierarchy only and denies all other access on the device. To do this, the user permissions includeconfigure
to provide configuration access. In addition, theallow-configuration
statement allows access to the interfaces configuration, and thedeny-configuration
statement denies access to all other configuration hierarchies. Because the allow statement takes precedence over the deny statement, the users assigned to the Class1 login class can access only the[edit interfaces]
hierarchy level. -
Class2—Defines access privileges for the user with the
allow-configuration-regexps
anddeny-configuration-regexps
statements. This login class provides superuser-level user permissions and explicitly allows configuration under multiple hierarchy levels for interfaces. It also denies access to the[edit system]
and[edit protocols]
hierarchy levels.
Router R1 has two users, User1 and User2, assigned to the Class1 and Class2 login classes, respectively.
Configuration
- CLI Quick Configuration
- Configure Authentication Parameters for Router R1
- Configure Access Privileges with the allow-configuration and deny-configuration Statements (Class1)
- Configure Access Privileges with the 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
in 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 secret "$ABC123" 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 destination tacplus server 10.209.1.66 secret "$ABC123" 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
Configure Authentication Parameters for Router R1
Step-by-Step Procedure
To configure Router R1 authentication:
-
Configure the order in which R1 attempts to authenticate the user. In this example, TACACS+ server authentication is first, followed by RADIUS server authentication, and then the local password.
[edit system] user@R1# set authentication-order tacplus user@R1# set authentication-order radius user@R1# set authentication-order password
-
Configure the TACACS+ server.
[edit system] user@R1# set tacplus-server 10.209.1.66 secret "$ABC123" user@R1# set tacplus-options enhanced-accounting user@R1# set accounting destination tacplus server 10.209.1.66 secret "$ABC123"
-
Configure the RADIUS server.
[edit system] user@R1# set radius-server 10.209.1.66 secret "$ABC123" user@R1# set radius-options enhanced-accounting
-
Configure the R1 accounting parameters.
[edit system] user@R1# set accounting events login user@R1# set accounting events change-log user@R1# set accounting events interactive-commands
Configure Access Privileges with the allow-configuration and deny-configuration Statements (Class1)
Step-by-Step Procedure
To specify regular expressions using the allow-configuration
and deny-configuration
statements:
-
Configure the Class1 login class with
configure
permissions.[edit system login] user@R1# set class Class1 permissions configure
-
Configure the
allow-configuration
regular expression to allow users in the class to view and modify part of the[edit interfaces]
hierarchy level.[edit system login] user@R1# set class Class1 allow-configuration "interfaces .* unit .*"
-
Configure the
deny-configuration
regular expression to deny access to all configuration hierarchies.[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 user User1 uid 2004 user@R1# set user User1 class Class1 user@R1# set user User1 authentication encrypted-password "$ABC123"
Configure Access Privileges with the allow-configuration-regexps and deny-configuration-regexps Statements (Class2)
Step-by-Step Procedure
To specify regular expressions using the
allow-configuration-regexps
and
deny-configuration-regexps
statements:
-
Configure the Class2 login class and assign superuser (all) permissions.
[edit system login] user@R1# set class Class2 permissions all
-
Configure the
allow-configuration-regexps
regular expression to allow users in the class to access 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" ]
-
Configure the
deny-configuration-regexps
regular expression to prevent users in the class from viewing or modifying the configuration at the[edit system]
and[edit protocols]
hierarchy levels.[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 user User2 uid 2006 user@R1# set user User2 class Class2 user@R1# set user User2 authentication encrypted-password "$ABC123"
Results
In configuration mode, confirm your configuration by entering the show
system
command. If the output does not display the intended
configuration, repeat the instructions in this example to correct the
configuration.
user@R1# show system authentication-order [ tacplus radius password ]; radius-server { 10.209.1.66 secret "$ABC123"; } tacplus-server { 10.209.1.66 secret "$ABC123"; } radius-options { enhanced-accounting; } tacplus-options { enhanced-accounting; } accounting { events [ login change-log interactive-commands ]; destination { tacplus { server { 10.209.1.66 secret "$ABC123"; } } } } 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.
Verify the Class1 Configuration
Purpose
Verify that the permissions allowed in the Class1 login class are working.
Action
In operational mode, check the available commands.
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
In configuration mode, check the available configuration permissions.
User1@R1# edit ? Possible completions: > interfaces Interface configuration
Meaning
User1 has configure
user permissions, as seen in the first
output. Additionally, in configuration mode, User1 has access to the
interfaces
hierarchy level, but only that hierarchy
level, as seen in the second output.
Verify the Class2 Configuration
Purpose
Verify that the Class2 configuration is working as expected.
Action
In configuration mode, access the interfaces
configuration.
[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
In 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 on R1, but the user does not
have permission to view or modify the [edit system]
or
[edit protocols]
hierarchy levels.