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. For information about CLI commands, see
the JUNOS CLI User Guide.
Note:
The all login class permission flags take
precedence over extended regular expressions when a user with rollback permission issues the rollback command.
Expressions used to allow and deny commands for users on RADIUS/TACACS+
servers have been simplified. Instead of a single, long expression
with multiple commands (for example, allow-command=cmd1 cmd2 cmdn), you can specify each command as a separate expression. This new
syntax is valid for allow-configuration, deny-configuration, allow-command, deny-command, and user-permissions.
Users cannot issue the load override command
when specifying an extended regular expression. Users can only issue
the merge, replace, and patch configuration
commands.
This section describes how to define a user’s
access privileges to individual operational and configuration mode
commands. It contains the following topics:
You can specify extended regular expressions with
the allow-command and deny-command statements to
define a user’s access privileges to individual operational
commands. Doing so takes precedence over login class permission flags
set for a user. You can include one deny-command statement
and one allow-command statement in each login class.
To explicitly allow an individual operational mode
command that would otherwise be denied, include the allow-command statement at the [edit system login class class-name] hierarchy level:
[edit system login class class-name]
allow-command “regular-expression”;
To explicitly deny an individual operational mode
command that would otherwise be allowed, include the deny-command statement at the [edit system login class class-name] hierarchy level:
[edit system login class class-name]
deny-command “regular-expression”;
If the regular expression contains any spaces,
operators, or wildcard characters, enclose it in quotation marks.
Regular expressions are not case-sensitive.
Use extended regular expressions to specify which
operational mode commands are denied or allowed. You specify these
regular expressions in the allow-command and deny-command statements at the [edit system login class] hierarchy level,
or by specifying attributes specific to JUNOS in your TACACS+ or RADIUS
authentication server configuration. You must specify that these regular
expressions are sent as the value of Juniper Networks vendor-specific
attributes. If regular expressions are received during TACACS+ or
RADIUS authentication, they merge with any regular expressions configured
on the local router. For information about TACACS+ or RADIUS authentication,
see the JUNOS System Basics Configuration Guide.
Command regular expressions implement the extended
(modern) regular expressions as defined in POSIX 1003.2. Table 5 lists common regular expression operators.
Table 5: Common
Regular Expression Operators to Allow or Deny Operational Mode Commands
Operator
Match...
|
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. For example, (show system alarms)|(show system software).
^
At the beginning of an expression, used to denote where the
command begins, and where there might be some ambiguity.
$
Character at the end of a command. Used to denote a command
that must be matched exactly up to that point. For example, allow-command
"show interfaces$" means that the user can issue the show
interfaces command but cannot issue the show interfaces detail or show interfaces extensive command.
[ ]
Range of letters or digits. To separate the start and end of
a range, use a hyphen ( - ).
( )
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 always be used in conjunction with pipe
operators as explained previously.
If a regular expression contains a syntax error,
it becomes invalid, and although the user can log in, the permission
granted or denied by the regular expression does not take effect.
When regular expressions configured on TACACS+ or RADIUS servers are
merged with regular expressions configured on the router and the final
expression has a syntax error, the overall result is an invalid regular
expression. If a regular expression does not contain any operators,
all varieties of the command are allowed. For example, if the following
statement is included in the configuration, the user can issue the
commands show interfaces detail and show interfaces
extensive in addition to showing an individual interface:
allow-command "show interfaces"
Example: Defining Access
Privileges to Individual Operational Mode Commands
The following examples define user access privileges
to individual operational mode commands.
If the following statement is included in the configuration
and the user does not have the configure login class permission
flag, the user can enter configuration mode:
[edit system login class class-name]
user@host# set allow-command configure
If the following statement is included in the configuration
and the user does not have the configure login class permission
flag, the user can enter configuration exclusive mode:
[edit system login class class-name]
user@host# setallow-command "configure exclusive"
Note:
You cannot use runtime variables. In the following
example, the runtime variable 1.2.3.4 cannot be used:
[edit system login class class-name]
user@host# set deny "show bgp neighbor 1.2.3.4"
Example: Configuring Access
Privileges to Individual Operational Mode Commands
Configure permissions for individual operational
mode commands:
[edit]
system {
login {
# This login class has operator privileges and the additional
ability to
# reboot the router.
class operator-and-boot {
permissions [ clear network reset trace view ];
allow-commands "request system reboot";
}
# This login class has operator privileges but can't use
any command that
# begins with “set.”
class operator-no-set {
permissions [ clear network reset trace view ];
deny-commands "^set";
}
# This login class has operator privileges and can install
software but not
# view bgp information, and can invoke show route without specifying commands
# or arguments under it.
class operator-and-install-but-no-bgp {
permissions [ clear network reset trace view ];
allow-commands "(request system software add)|(show route)";
deny-commands "show bgp";
}
}
}
Specifying Configuration Mode Commands
You can specify extended regular expressions with
the allow-configuration and deny-configuration attributes
to define user access privileges to parts of the configuration hierarchy
or individual configuration mode commands. Doing so overrides any
login class permission flags set for a user. You can also use wildcards
to restrict access. When you define access privileges to parts of
the configuration hierarchy or individual configuration mode commands,
do the following:
Specify the full paths in the extended regular expressions
with the allow-configuration and deny-configuration attributes.
Enclose parentheses around an extended regular expression
that connects two or more expressions with the pipe | symbol. For
example:
[edit system login class class-name]
user@host# set deny-configuration "(system
login class) | (system services)"
Note:
Each expression separated by a pipe | symbol must
be a complete standalone expression, and must be enclosed with parentheses
( ). Do not use spaces between regular expressions separated by parentheses
and connected with the pipe | symbol. You cannot define access to
keywords such as set, edit, or activate.
For more information about how to use wildcards,
see Table 6.
To explicitly allow an individual configuration
mode command that would otherwise be denied, include the allow-configuration statement at the [edit system login class class-name] hierarchy level:
[edit system login class class-name]
allow-configuration “regular-expression”;
To explicitly deny an individual configuration
mode command that would otherwise be allowed, include the deny-configuration statement at the [edit system login class class-name] hierarchy level:
[edit system login class class-name]
deny-configuration “regular-expression”;
If the regular expression contains any spaces,
operators, or wildcard characters, enclose it in quotation marks.
Regular expressions are not case-sensitive.
You can include one deny-configuration and one allow-configuration statement in each login class.
Use extended regular expressions to specify which
configuration mode commands are denied or allowed. You specify these
regular expressions in the allow-configuration and deny-configuration statements at the [edit system login class] hierarchy level,
or by specifying attributes, that are specific to JUNOS, in your TACACS+
or RADIUS authentication server’s configuration. You must specify
that these regular expressions are sent as the value of Juniper Networks
vendor-specific attributes. If regular expressions are received during
TACACS+ or RADIUS authentication, they merge with any regular expressions
configured on the local router. For information about TACACS+ or RADIUS
authentication, see the JUNOS System Basics Configuration Guide.
Command regular expressions implement the extended
(modern) regular expressions, as defined in POSIX 1003.2. Table 6 lists common regular expression
operators.
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. For example, (show system alarms)|(show system software).
^
At the beginning of an expression, used to denote where the
command begins, and where there might be some ambiguity.
$
Character at the end of a command. Used to denote a command
that must be matched exactly up to that point. For example, allow-command
"show interfaces$" means that the user can issue the show
interfaces command but cannot issue the show interfaces detail or show interfaces extensive command.
[ ]
Range of letters or digits. To separate the start and end of
a range, use a hyphen ( - ).
( )
A group of commands indicating a complete, standalone expression
to be evaluated; the result is then evaluated as part of the overall
expression. Parantheses must always be used in conjunction with pipe
operators as explained previously.
*
Zero or more terms.
+
One or more terms.
.
Any character except for a space " ".
Example: Defining Access Privileges
to Individual Configuration Mode Commands
The following examples show how to configure access
privileges to individual configuration mode commands.
If the following statement is included in the configuration
and the user’s login class permission flag is set to all, the user cannot configure telnet parameters:
[edit system login class class-name]
user@host# set deny-configuration "system
services telnet"
If the following statement is included in the configuration
and the user’s login class permission flag is set to all, the user cannot issue login class commands within any login class
whose name begins with the letter m:
[edit system login class class-name]
user@host# set deny-configuration "system
login class m.*"
If the following statement is included in the configuration
and the user’s login class permission flag is set to all, the user cannot issue configuration mode commands at the system
login class or system services hierarchy levels:
[edit system login class class-name]
user@host# set deny-configuration "(system
login class) | (system services)"
Example: Configuring
Access Privileges to Individual Configuration Mode Commands
Configure permissions for individual configuration
mode commands:
[edit]
system {
login {
# This login class has operator privileges and the additional
ability to
# issue commands at the system services hierarchy.
class only-system-services {
permissions [ configure ];
allow-configuration "system services";
}
# This login class has operator privileges but can't issue
any system
