Description

This article describes the differences between the commands allow/deny-configuration and allow/deny-configuration-regexps , and how each expression changes user authorization.

 

Note: The following steps are also documented more formally here:  Example: Configuring User Permissions with Access Privileges for Configuration Statements and Hierarchies



Symptoms

Login-classes are configured under system login class and provide a means of controlling which parts of the configuration a user is authorized to view or edit, as well as which operational commands they can execute. Aside from basic permissions, a login-class may also list one more allow/deny expressions.  Former commands allow/deny-configuration are deprecated from Junos OS 11.4R1 and allow/deny-configuration-regexps commands are being introduced in Junos OS 11.4R1.  Currently,  the allow/deny-configuration commands are un-deprecated from Junos OS 11.4R6, and the commands allow/deny-configuration-regexps and allow/deny-configuration are both supported.  The commands allow/deny-configuration-regexps are not designed to work exactly the same as the former commands allow/deny-configuration .


Solution

The statements allow/deny-configuration-regexps split up the expression into tokens and matches each piece against each part of the knob's full path, whereas allow/deny-configuration matches  against the full string. The statement allow/deny-configuration-regexps is supposed to have better performance and get rid of ambiguity that existed when combining expressions set in allow/deny-configuration (Example 1, 2). On the other hand, allow/deny-configuration is also useful from the customer point of view, to keep configuration simple (Example 3).

Example 1.  Expression matching 1 token using " allow-configuration-regexps ":

This example shows options is the only matched expression against first token of statement. 

[edit system]
login {
    class tech-operator {
        permissions configure;
        allow-configuration-regexps .*options;
    }

This will match the following statements: 

	* set policy-options condition xxxxx dynamic-db
 	* set routing-options static route xx.xx.xx.xx/xx next-hop yy.yy.yy.yy
 	* set event-options generate-event xxxxx time-interval yy

This will not match the following statements: 
	* system host-name host-options
 	* interfaces ge-2/0/5 description options

Example 2. Expression matching 3 tokens using " allow-configuration-regexps ":

This example shows ssh is the only matched expression against third token of statement. 

[Edit system]
login{
    class ssh-user {
        permissions configure;
        allow-configuration-regexps ".* .* .*ssh";
    }
  
            ".* .* .*ssh"
             |   |    |
             |   |    +-----------------------------+
             |   |                                  v
     +-------+   |                   describes pattern to use
     |           +-----+             to match 3rd token
     |                 |
     v                 |
describes pattern      |
to use to match 1st    |
token                  |
                       |
                       v
             describes pattern to
             use to match 2nd token

This will match the following statements: 

	* system host-name xxx-ssh
 	* system services ssh
 	* system services outbound-ssh

This will not match the following statements: 
	* interfaces ge-2/0/15 description ssh

Example 3. Expression matching full string using " deny-configuration "  :

This example shows ssh is the matched expression against full string of statement (*1) . 

[Edit system]
login{
    class ssh-user {
        permissions configure;
        allow-configuration .*;
        deny-configuration ".*ssh";
    }

This will DENY to match the following statements : 

	* system host-name xxx-ssh
 	* system services ssh
 	* system services outbound-ssh
 	* security ssh-known-host host xxxx

(*1)  : allow/deny-configuration-regexps could make the configuration much more complex to use from the customer point of view when they try to block access.  Blocking everything related to ssh , deny-configuration is much easier with .*ssh .
  
[Edit system]
login{
    class ssh-user {
        permissions configure;
        allow-configuration-regexps .*;
        deny-configuration-regexps ".* .* .*ssh";
    }

This will DENY to match the following statements : 

	* system host-name xxx-ssh
 	* system services ssh
 	* system services outbound-ssh

This will NOT DENY to match the following statements : 

	* security ssh-known-host
If deny-configuration-regexps is used, it requires [".*ssh" ".* .*ssh" ".* .* .*ssh"], etc.,  plus other permutations to block everything related to ssh .
  
[Edit system]
login{
    class ssh-user {
        permissions configure;
        allow-configuration-regexps .*;
        deny-configuration-regexps ".*ssh";
        deny-configuration-regexps ".* .*ssh";
        deny-configuration-regexps ".* .* .*ssh";
    }

This will DENY to match the following statements : 

	* system host-name xxx-ssh
 	* system services ssh
 	* system services outbound-ssh
 	* security ssh-known-host



 

Modification History

2017-04-16: Added link to this example now documented in the technical documentation too.