[j-nsp] Juniper authorization with tacacs+

[Sukhjit Hayre]

Hi Ivan

The goal is for ACS to be able to control this otherwise I can argue what's the point in using ACS at all?

There are attributes which are supposed to be working for which I don't understand technically why they are not i.e allowed-commands (check the link)



> On 14 Apr 2015, at 10:49, Ivan Ivanov <ivanov.ivan at gmail.com> wrote:
> 
> Hi Sukhjit,
> 
> Why don't you use local template accounts to accomplish that?
> 
> http://www.juniper.net/documentation/en_US/junos13.3/topics/task/configuration/authentication-user-local-template-account-configuring.html
> 
> ACS should be able to push 'local-username' attribute via tacacs+.
> 
> HTH,
> Ivan,
> 
>> On Mon, Apr 13, 2015 at 11:58 PM, Sukhjit Hayre <sukhjit.hayre at googlemail.com> wrote:
>> 
>> 
>> yeah I've used this too and depending on the local profile it shows what I expect it too, but what it doesn't show is minus the ACS attributes if at all I would see that here...
>> 
>> I think a deeper packet inspection can identify what the messages are saying, will try to do that at some point
>> 
>> 
>> 
>> > On 13 Apr 2015, at 23:42, Chris Kawchuk <juniperdude at gmail.com> wrote:
>> >
>> > Show cli authorization. Should show you the current login credentials and such.
>> >
>> >> On 14 Apr 2015, at 8:23 am, Sukhjit Hayre <sukhjit.hayre at googlemail.com> wrote:
>> >>
>> >> hi Chris
>> >>
>> >> thanks for the reply, actually I did not see any user file in /var/tmp
>> >> whilst logged-in im running vSRX firefly 12.1X47-D10.4
>> >>
>> >> On Mon, Apr 13, 2015 at 4:07 PM, Chris Morrow <morrowc at ops-netman.net>
>> >> wrote:
>> >>
>> >>>
>> >>>
>> >>>> On 04/13/2015 11:01 AM, Eduardo Barrios wrote:
>> >>>> When I tested this a while back I could not get the "allow-commands"
>> >>>> attribute to work. The deny-commands attribute does work however. So
>> >>>> our ACS shell-profile read only group we had to start with a junos
>> >>>> login with a super-user class then use the "deny-commands" attribute
>> >>>> to strip the access ...request, restart, configure, etc.
>> >>>
>> >>> it might help you to look in /var/tmp on the juniper when the affected
>> >>> user is logged in.. there will be a file named per the user's login PID
>> >>> which has their access requirements outlined. You can probably reverse
>> >>> engineer the right answer from that data.
>> >>> _______________________________________________
>> >>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >> _______________________________________________
>> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> 
> 
> -- 
> Best Regards!
> 
> Ivan Ivanov