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