[j-nsp] Juniper authorization with tacacs+

[Ivan Ivanov]

Hi Sukhjit,

The idea with local templates is that you configure couple of them or more
with different privileges. Then using the ACS you control which user which
template to inherit. If you look in the link you will see that those local
templates look like users but they do not have authentication attached. So
he only way to be used is if they are pushed from authentication server.

For example you configure two templates with different privileges and
assign hundred users from ACS to one of them and other hundred to the
other. That is why they are called templates.

This is usually how is done on Junos to have users with different
privileges authenticated via RADIUS or TACACS+ servers.

I hope now is more clear to you!
Ivan,

On Tue, Apr 14, 2015 at 11:08 AM, Sukhjit Hayre <
sukhjit.hayre at googlemail.com> wrote:

>
>
> 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
>
>


-- 
Best Regards!

Ivan Ivanov