[Contents] [Prev] [Next] [Index] [Report an Error]

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 login class permission bits 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 in parentheses ( ). Do not use spaces between regular expressions separated with 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 13.

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 Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your authentication server’s configuration. 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 Configuring System Authentication.

Command regular expressions implement the extended (modern) regular expressions, as defined in POSIX 1003.2. Table 13 lists common regular expression operators.

Table 13: Configuration Mode Commands—Common Regular Expression Operators

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, 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-commands "show interfaces$" means that the user can issue the show interfaces command but cannot issue show interfaces detail or show interfaces extensive.
[ ]	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 above.
*	Zero or more terms.
+	One or more terms.
.	Any character except for a space " ".

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 bit 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 bit is set to all, the user cannot issue login class commands within any login class whose name begins with “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 bit is set to all, the user cannot issue configuration mode commands at the login class or system services hierarchy levels:



[edit system login class class-name]
user@host# set deny-configuration "(system
login class) | (system services)"

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


class only-system-services {
permissions [ configure ];
allow-configuration "system services";
}


# This login class has operator privileges but cannot issue
any system
# services commands.


class all-except-system-services {
permissions [ all ];
deny-configuration "system services";
}


}


}

[Contents] [Prev] [Next] [Index] [Report an Error]