Routing
Highlighted
Routing

User Access Block For Some Commands

‎11-10-2012 11:13 PM

Hi There,


We have requirement to deny below command to users. We have been trying multiple combination also using with regexp but so far we have not found any luck.
Can you please share you thought for a way out on this requirement?
or is this possible to deny such command ?

"delete interfaces"
"delete protocols"

below is currnet login configuration we have :

apply-groups deny_show_bgp_group;
class L1-Front {
    idle-timeout 10;
    permissions [ network secret security trace view view-configuration ];
}
class L1-Plan {
    idle-timeout 10;
    permissions [ network secret security trace view view-configuration ];
    allow-commands "monitor traffic";
    deny-commands "(clear)|(show bgp group)";
}

 

When we use deny-command "(delete interfaces)" in above classes the users belong to these classes still able to delete interfaces. Please check



BR,

8 REPLIES 8
Highlighted
Routing

Re: User Access Block For Some Commands

‎11-11-2012 09:20 AM

Hi there,

 

 Can you also paste what "deny_show_bgp_group" is please? The classes L1-Front and L1-Plan should not even be able to do a configure and/or edit, so they can't do any delete as is now.

 

 Cheers,

____________________________________________
If you think your question's answered, please
mark the respective post as "Accepted Solution".

Kudos are an excellent way of showing appreciation, too.
Highlighted
Routing
Solution
Accepted by topic author r@thore
‎08-26-2015 01:27 AM

Re: User Access Block For Some Commands

‎11-11-2012 11:03 AM

 

Hey there,

 

 While waiting for your reply, I'd like to take a guess and asssume you're after something like below:

 

"A limited user class that can do some things on the router, including configuring interfaces but do not delete all of them."

 

In this case, I would suggest a different approach than your initial example, as the one below:

 

class Limited-Class {
    idle-timeout 15;
    permissions [ access clear firewall interface maintenance network pgcp-session-mirroring reset rollback routing secret security snmp storage system trace view view-configuration ];
    allow-commands configure;
    allow-configuration "(interfaces .*)|(^class-of-service .*)|(firewall .*)";
}
user erdem {
    uid 5555;
    class Limited-Class;
}

  Note that instead of giving the user permissions all or interface-control (-control means read-write access to that part of the configuration) I've given only the "interface" permission, which is read-only.

 

 However, the class is explicitly allowed to use the configure command (so that the user can enter configuration mode) along with three regular expressions in allow-configuration statement, allowing them to configure/delete a specific interface, COS or firewall item but NOT entirely alter their configuration.

 

 In other words, the " .*" in the regexp forces the user to specify at least one more level in the following stenzas, which they can alter:

 

[edit interfaces]

[edit class-of-service]

[edit firewall]

 

 

 Although their permissions give only read-write access to them, the explicit allow-configuration will take precedence and overwrite.

 

 Logged in as user 'erdem', see what will happen if I try to configure/delete a specific interface, or all of them below. Note that the auto-complete is NOT going to work with edit interfaces command because user erdem has no permission bit interface-control set, so I have to type the whole command manually.

 

erdem@vetinari> configure
Entering configuration mode
[edit]
erdem@vetinari# edit in
                     ^
syntax error, expecting <statement> or <identifier>.
erdem@vetinari# edit in?  
No valid completions
[edit]
erdem@vetinari# edit interfaces

[edit interfaces]
erdem@vetinari# delete
Delete everything under this level? [yes,no] (no) yes

error: permission denied for interfaces: delete

edit interfaces]
erdem@vetinari# set ge-0/0/10 description test

[edit interfaces]
erdem@vetinari# commit
commit complete

[edit interfaces]
erdem@vetinari# show ge-0/0/10
description test;

[edit interfaces]
erdem@vetinari# delete ge-0/0/10

[edit interfaces]
erdem@vetinari# commit
commit complete

[edit interfaces]
erdem@vetinari# show ge-0/0/10

[edit interfaces]
erdem@vetinari#

 

    Needless to say, you can play with allow-configuration and permissions in the class to better suit your need.

 

  Hope this helps,

 

 

 

 

 

____________________________________________
If you think your question's answered, please
mark the respective post as "Accepted Solution".

Kudos are an excellent way of showing appreciation, too.
Highlighted
Routing

Re: User Access Block For Some Commands

‎11-11-2012 04:24 PM

Hi Erdems,

 

Thanks for your detailed email, its really helpful.

 

Basically the customer requirement is exactly that the user have permission all flag but not able to delete/deactivate interfaces or protocol. So, i tried multiple combination but it didn't work. I also used regular expression but it didn't work. User still have permission to use delete/deactivate interfaces or protocol.

 

Like,

 

permissions all

deny-commands "(delete interfaces) | (deactivate interfaces) | (delete protocols) | (deactivate protocols) "

 

As i read documentation that deny or allow commands always accepted either permissions flag are on.

 

Please comment. Thanks

 

Regards,

 

 

Highlighted
Routing

Re: User Access Block For Some Commands

[ Edited ]
‎11-11-2012 06:51 PM

 

Hey there,

 

 Now I see. You need to use deny-configuration knob for that:

 

[edit system login]
erdems@vetinari# show 
class Limited-2 {
    permissions all;
    deny-configuration "interfaces$|protocols$";
allow-configuration "interfaces .+|protocols .+" } user erdem { uid 5555; idle-timeout 15; class Limited-2; authentication { encrypted-password "$1$Q4h2.UmA$NDdO4Mrc88Ajr65P04FM41"; ## SECRET-DATA } }

 The above configuration would grant all possible permissions (including start shell, which you may want to avoid too, in case the concern is more focused on security than preventing mistakes) except any set/delete/deactivate command for interfaces, without a suffix.

 

 In other words the users in that class can issue a "delete interfaces xe-0/0/0" but NOT "delete interfaces" and can do a "delete protocols bgp" but NOT "delete protocols", as you can see below.

 

[edit]
erdem@vetinari# delete interfaces 
error: permission denied for interfaces: interfaces

[edit]
erdem@vetinari# delete protocols 
error: permission denied for protocols: protocols

erdem@vetinari# delete interfaces ge-0/0/1 

[edit]
erdem@vetinari# delete protocols mpls 

[edit]
erdem@vetinari# show | compare | count 
Count: 25 lines

[edit]
erdem@vetinari#

 

 

 Once again, I would recommend giving thought on what exactly is targeted with this approach.

 

 If it's a simple precaution against fast-typers, then this should be enough. However, if security is a concern IMHO the restrictions should be higher, as in my first post.

 

 FYI, allow-configuration and deny-configuration knobs are fully supported back again from JUNOS 12.1 onwards.

 

 Hope this helps,

____________________________________________
If you think your question's answered, please
mark the respective post as "Accepted Solution".

Kudos are an excellent way of showing appreciation, too.
Highlighted
Routing

Re: User Access Block For Some Commands

‎11-12-2012 02:01 AM

Hi Eredems,

 

Thanks for detailed email. Is it possible to modify below example and to block "delete interfaces interface-name" as well.

 

Thanks

 

Highlighted
Routing

Re: User Access Block For Some Commands

‎11-12-2012 01:49 PM
Hey there, Let me take a step back and ask you this. Normally, 'permissions all' will give in [edit interfaces] section the following rights (partially, or full) - edit an existing configuration - delete an existing configuration - add a new configuration I'm not sure whether adding delete interfaces to the regexp will be the answer for you if you're not happy with the ability of set interfaces for the class either. The way I see it, the easiest for you would be to manually add the permissions with "-control" and include interface *without* the '-control' suffix, which would grant read-only access to interfaces and inherited (e.g. COS) sections. Cheers,
____________________________________________
If you think your question's answered, please
mark the respective post as "Accepted Solution".

Kudos are an excellent way of showing appreciation, too.
Highlighted
Routing

Re: User Access Block For Some Commands

‎11-12-2012 10:09 PM

Hi Ederms,

 

Thanks for help throughout the way.

 

Highlighted
Routing

Re: User Access Block For Some Commands

‎10-21-2019 12:17 PM
Great. You are genious.
Feedback