Le lun. 4 juil. 2022 à 16:43, Saku Ytti <s...@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 <s...@ytti.fi> a écrit : > > I believe this is best you can do: > > y...@a03.labxtx03.us.bb-re0# show|display set |match deny > set system login class tacacs-user deny-commands "clear pppoe > sessions($| no-confirm$)" > > y...@a03.labxtx03.us.bb-re0> clear pppoe sessions ? > Possible completions: > <interface> Name of PPPoE logical interface > y...@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$)" _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
