Junos Automation (Scripting)
Highlighted
Junos Automation (Scripting)

Command filtering for user access via netconf

‎07-24-2020 12:17 PM

Hi


I have a user which is connecting to the router via netconf (via pyez) - I want to give him permission only to deactivate interfaces and here is the problem that I don't know how to do it 😉 - the script itself is very easy - it looks like this:

from jnpr.junos import Device
from jnpr.junos.utils.config import Config
from jnpr.junos.exception import ConfigLoadError, CommitError

dev = Device(host='router1')
dev.open()

with Config(dev, mode='private') as cu:  
    try:
        cu.load("deactivate interfaces ge-0/0/3 unit 10", format='set')
        cu.commit()
    except (ConfigLoadError, CommitError) as err:
        print (err)

dev.close()

and if I'm logging via user account with super-user class - everything is working flawlessly - the problem starts when I want to create custom class with permission to apply only deactivate command.
From what I checked it seems that standard allow-commands doesn't work

In interactive-command log I have something like this:
mgd[12793]: UI_NETCONF_CMD: User 'abc' used NETCONF client to run command 'load-configuration action="set" format="text"'
mgd[12793]: UI_CMDLINE_READ_LINE: User 'abc', command 'rpc load-configuration deactivate interfaces ge-0/0/3 unit 20 '
mgd[12793]: UI_NETCONF_CMD: User 'abc' used NETCONF client to run command 'commit-configuration'


of course I tried to add those commands to allow-commands and in deny-commands everything else (.*) but it doesn't work either - I'm getting permission denied
This is the output from netconf traceoptions:
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</capability>
<capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
<capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
<capability>http://xml.juniper.net/netconf/junos/1.0</capability>
<capability>http://xml.juniper.net/dmi/system/1.0</capability>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: </capabilities>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <session-id>9082</session-id>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: </hello>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: ]]>]]>
Jul 24 18:30:48 [NETCONF] - [9082] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"><nc:capabilities><nc:capability>urn:ietf:params:netconf:capability:writable-running:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:with-defaults:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</nc:capability><nc:capability>urn:liberouter:params:netconf:capability:power-control:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:validate:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file,https,sftp</nc:capability><nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:base:1.1</nc:capability><nc:capability>urn:ietf:params:netconf:capability:candidate:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:notification:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:xpath:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:startup:1.0</nc:capability><nc:capability>urn:ietf:params:netconf:capability:interleave:1.0</nc:capability></nc:capabilities></nc:hello>]]>]]>
Jul 24 18:30:48 [NETCONF] - [9082] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:ed463a32-7324-4171-80fd-1c3472188602"><open-configuration><private/></open-configuration></nc:rpc>]]>]]>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.2R1/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:ed463a32-7324-4171-80fd-1c3472188602">
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <rpc-error>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <error-type>protocol</error-type>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <error-tag>operation-failed</error-tag>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <error-severity>error</error-severity>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <error-message>permission denied</error-message>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <error-info>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: <bad-element>open-configuration</bad-element>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: </error-info>
Jul 24 18:30:48 [NETCONF] - [9082] Outgoing: </rpc-error>

Any help/ideas/propositions how to do it and the main question is - if this is possible to filter those commands ?

9 REPLIES 9
Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-24-2020 01:01 PM

Hi Nelreth,

 

Could you provide sample of the class config which you used ? I believe that deactivate and activate should be in allowed-config not allowed commands, as they are config statements and not commands.

 

Please mark "Accept as solution" if this answers your query.

Best Regards,

Mohamed

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-25-2020 05:40 AM

Hi Mohamed,

 

Thanks for the replay - unfortunately, I can't force it to work 😉
Here is my class configuration attached to the user:
set system login class tabc idle-timeout 30
set system login class tabc login-alarms
set system login class tabc permissions configure
set system login class tabc permissions interface-control
set system login class tabc permissions view
set system login class tabc allow-configuration-regexps "interfaces ge-0/0/3"

 

with this config I can edit all interfaces - not only ge-0/0/3 - but with that config I still can e.g. delete interfaces - and this is what I would like to avoid and allow only for deactivate.

The final question is if I'm connecting via netconf is this configuration (allow/deny-commands/configuration) is even checked/used ?

 

Best regards

Adam

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-25-2020 08:52 AM

Hi Adam,

 

Could you try the class similar to below ? As, the netconf use user account to access the router, it should have the same privilege as the user account.

 

labroot@diocletian-re0# show system login class user
permissions view;
allow-commands "configure|edit|configure private|configure exclusive";
allow-configuration-regexps "interfaces xe-3/0/0 .*";

 

Please mark "Accept as solution" if this answers your query.

 

Best Regards,

Mohamed

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-26-2020 02:58 AM

Hi Mohamed,

 

Thanks for the answer. I applied Your configuration but when I try to connect via netconf I instantly get error:

$ ssh -s abc@10.1.1.1 -p 22 netconf
Password:

error: unknown command: xml-mode

error: permission denied: netconf


So I added few things and it looks like this right now:
allow-commands "configure|edit|configure private|configure exclusive|.*xml-mode|.*need-trailer|.*netconf|exit";

and now I'm able to login via netconf - unfortunately, I'm still have a problem even to open configuration - after I send this command:
<?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:58a47144-e2be-4fb4-a884-d55801d07e5d"><open-configuration><private/></open-configuration></nc:rpc>]]>]]>

I get reply:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.2R1/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:58a47144-e2be-4fb4-a884-d55801d07e5d">
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-message>permission denied</error-message>
<error-info>
<bad-element>open-configuration</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
]]>]]>

that's of course with enabled this line in config:
deny-commands .*;

if I deactivate deny-commands everything is working properly - this is what I cannot breakthrough - even with "configure private" in allowed commands, it doesn't work when I try to do it via netcon

of course if I'm login to the router via CLI - configure private works properly:

abc> configure private
warning: uncommitted changes will be discarded on exit
Entering configuration mode

[edit]
abc#

 

Best Regards

Adam

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

[ Edited ]
‎07-26-2020 05:48 AM

Hi Adam,

 

Why this part was added "deny-commands .*" ? I mean, Why is it needed in this context ?

"deny-commands .*" affects the commands run on cli mode not the config mode. 

 

Please mark "Accept as solution" if this answers your query.

 

Best Regards,

Mohamed

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-26-2020 07:18 AM

Hi Mohamed,

 

Thanks for replay.
I would like to give to this "abc" user least privileges as I can - ideally - he should be able to enter into configuration mode and deactivate interface/unit - that's all (without any delete/set/rename/etc.)
That's why I thought that I will add only necessary commands via allow-commands and deny everything else - and it works as expected if I'm connecting via ssh/cli - but not via netconf

It seems like commands which I enter via netconf are not checked with allow/deny-commands or they have different syntax (or something)

Best regards
Adam

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-26-2020 09:34 AM

Hi Adam,

deny-commands/allow-commands statements are not related to allowed denied config. It`s related to denied allowed-command in operational mode. Similar to "show version", etc.

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/cli-overview.html

 

To deny/allow config you need deny-config/allow-config statements. These are used to allow or deny configuration hierarchy like interfaces or part of hierarchy, and I dont think it could be used to allow/deny the set/delete/activate or similar commands.

 

Other than this you also can assign permissions to view/configure certain hierarchy.

 

In the example, which I provided earlier, the user do not have any permission except the view, and view-config, you can remove them if you prefer of-course, as they are not needed in this case you mentioned. Without have any config permission, the user wont be able to configure.

 

Using the below allow-commands, will give the user exception to enter the config mode,(of course you can add the same modification you mentioned for netconf). Another way to do this is to  give the user permission configure to enter the config mode with using this exception.

Using the below allow-config will give the user exception to only configure with this interface hierarchy. 

 

show configuration system login class user
permissions [ view view-configuration ];
allow-commands "configure|edit|configure private|configure exclusive";
allow-configuration-regexps "interfaces xe-3/0/0 .*";

 

Here is also, the o/p of cli authorization, which shows which actions can be done by this user.

moh@router> show cli authorization
Current user: 'moh ' class 'user'
Permissions:
view -- Can view current values and statistics
view-configuration-- Can view all configuration (not including secrets)
Individual command authorization:
Allow regular expression: configure|edit|configure private|configure exclusive
Deny regular expression: none
Allow configuration regular expression: "interfaces xe-3/0/0 .*"
Deny configuration regular expression: none 

 

Here is also,  more detailed reference on how to create users/classes

 

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/junos-os-access-privileges.html#i...

 

Let me know if you have other queries regarding this.

 

Please mark "Accept as solution" if this answers your query.

Best Regards,

Mohamed

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-28-2020 08:54 AM

Hi Mohamed,

 

Thanks again for such - extensive answer 🙂

Your config (with permission view and allow-configuration-regexps) is closest to what I would like to achieve - only interfaces are available to view and modify.
The last part which - I don't know if this is even possible - to deny delete command.

As You wrote deny-command works fine for operational mode but not in config mode - that's why I start to doubt if this is even possible (right now I don't think even about netconf but straight CLI access)

Best regards

Adam

Highlighted
Junos Automation (Scripting)

Re: Command filtering for user access via netconf

‎07-28-2020 12:07 PM

re this: "


. . .
The last part which - I don't know if this is even possible - to deny delete command.

As You wrote deny-command works fine for operational mode but not in config mode - that's why I start to doubt if this is even possible (right now I don't think even about netconf but straight CLI access)
. . .

If a user has permission to edit the config, then the only way you can implement the type of restriction you want would be via a commit script.  It would be possible then, but it would be unpleasant.  And fragile. 

 

From the commit script you can tell the user/class of who's committing the change  ($junos-context/user-context/login-name and $junos-context/user-context/class-name) .  You can also tell what was changed in the candidate config by examining @junos:changed.     Then you'd apply whatever your rules are for 'permitted change or not'.   Fail the commit if something is out of whack; else commit.

 

/doug

--
"There he goes. One of God's own prototypes. A high-powered mutant of some kind never even considered for mass production. Too weird to live, and too rare to die." --HST
Feedback