[j-nsp] Tacacs command authorization not working as intended
Pierre Emeriaud
petrus.lt at gmail.com
Wed Jul 6 07:21:05 EDT 2022
Le lun. 4 juil. 2022 à 16:43, Saku Ytti <saku at ytti.fi> a écrit :
>
> I don't believe what you're doing is tacacs command authorization, that is junos is not asking the tacacs server if or not it can execute the command, something IOS and SROS can do, but which makes things like loading config very brutal (except SROS has way to skip authorization for config loads).
>
> You are shipping config to the router for its allow-commands/deny-commands. And I further believe behaviour you see is because there is distinction between key and values, and you cannot include values in it. Similar problem with 'apply-groups', because the parser doesn't know about values and you're just telling what exists in the parser tree and what does not.
You're absolutely right. This is imho an acceptable tradeoff if
everything works.
Le lun. 4 juil. 2022 à 17:03, Saku Ytti <saku at ytti.fi> a écrit :
>
> I believe this is best you can do:
>
> ytti at a03.labxtx03.us.bb-re0# show|display set |match deny
> set system login class tacacs-user deny-commands "clear pppoe
> sessions($| no-confirm$)"
>
> ytti at a03.labxtx03.us.bb-re0> clear pppoe sessions ?
> Possible completions:
> <interface> Name of PPPoE logical interface
> ytti at a03.labxtx03.us.bb-re0> clear pppoe sessions
>
> You can't clear all, but you can clear any.
Thanks Saku, much appreciated. this works well, although I still have
to allow 'clear' permission and refuse all other commands.
deny-commands = "clear [a-o].*|clear [q-z].*|clear p[^p].*|clear pppoe
sessions($| no-confirm$)"
More information about the juniper-nsp
mailing list