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

Specifying Operational Mode Commands

You can specify extended regular expressions with the allow-commands and deny-commands statements to define a user’s access privileges to individual operational commands. Doing so takes precedence over login class permission bits set for a user. You can include one deny-commands and one allow-commands statement in each login class.

To explicitly allow an individual operational mode command that would otherwise be denied, include the allow-commands statement at the [edit system login class class-name] hierarchy level:



[edit system login class class-name]

allow-commands "regular-expression”;

To explicitly deny an individual operational mode command that would otherwise be allowed, include the deny-commands statement at the [edit system login class class-name] hierarchy level:



[edit system login class class-name]

deny-commands "regular-expression”;

If the regular expression contains any spaces, operators, or wildcard characters, enclose it in quotation marks. Regular expressions are not case-sensitive.

Note: Modifiers are not supported within the regular expression string to be matched. If a modifier is used, then nothing is matched.

For example, the deny command set protocols does not match anything whereas protocols matches protocols.

Use extended regular expressions to specify which operational mode commands are denied or allowed. You specify these regular expressions in the allow-commands and deny-commands statements at the [edit system login class] hierarchy level, or by specifying Juniper Networks vendor-specific TACACS+ or RADIUS attributes in your authentication server 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 12 lists common regular expression operators.

Table 12: Common Regular Expression Operators to Allow or Deny Operational Mode Commands

Operator	Match
\|	One of two or more terms separated by the pipe (\|) symbol. 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-commands "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 above.

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 merge with regular expressions configured on the router, if 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-commands "show interfaces";

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 bit, the user can enter configuration mode:



[edit system login class class-name]
user@host# set allow-commands configure

If the following statement is included in the configuration and the user does not have the configure login class permission bit, the user can enter configuration exclusive mode:



[edit system login class class-name]
user@host# set allow-commands "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-commands "show bgp neighbor
1.2.3.4"

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 commands beginning
 # 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 issue the show route command,
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";
}


}


}

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