Re: [f-nsp] AAA, TACACS, some users enabled on login, others not

Brocade has the brocade specific brocade-privlvl, with three different
levels of access as I remember, 1, 4 and 5.  The mapping between the two is
not always good.  For instance, on Brocade, as I remember, 1 on Cisco maps
to 4 of Brocade, which is just stupid - it should map to 5.  (Granted, this
was years ago, it may have changed)  As a shameless plug, it's not hard to
do modify this with tac_plus & do_auth provided you can distinguish by
device IP.  You can authorize by priv levels or commands.  I wrote about it
years ago here:

http://www.tacacs.org/tacacsplus/2012/02/06/disable-account-on-brocade

On Sat, Nov 5, 2016 at 1:32 PM, Eldon Koyle <
[email protected]> wrote:

> I did notice that document says privlvl and not priv-lvl.  Depending on
> what you changed, you may be able to see the enable attempt on the tacacs
> server (it may just be expecting the same username/password with admin
> privs on tacacs).
>
> On Nov 5, 2016 11:06 AM, "Tom Storey" <[email protected]> wrote:
>
>> Hi Eldon,
>>
>> Thanks for pointing me to this document.
>>
>> If I understand it correctly, my existing configuration should have been
>> working just fine as it is. Since I wasnt specifying the "foundry-privlvl"
>> attribute, it should look for the last exec attribute with a number in it
>> and treat that number as the priv level. In my case Im using "priv-lvl"
>> with a value of 15 for my Cisco devices, so the Brocade should have
>> translated that to mean level 0 given a lack of "foundry-privlvl" attribute.
>>
>> But for what ever reason that doesnt seem to be working. So I also tried
>> specifying it explicitly in my config, including removing the priv-lvl
>> attribute, but still to no avail.
>>
>> Ive managed to lock myself out of my test device now (can no longer
>> enable, its asking for a username, doh!), its in the office and Im at home.
>> So I guess I'll resume on Monday if anyone else comes up with anything. :-)
>>
>> Thanks
>> Tom
>>
>> On 4 November 2016 at 20:53, Eldon Koyle <ekoyle+puck.nether.net@gmail.
>> com> wrote:
>>
>>> We use foundry-privlvl = 0 for admin access.
>>>
>>> See also: http://www.brocade.com/content/html/en/configuration-guide/F
>>> I_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html
>>>
>>> --
>>> Eldon
>>>
>>> On Fri, Nov 4, 2016 at 5:26 AM, Tom Storey <[email protected]> wrote:
>>> > Hi everyone,
>>> >
>>> > Implementing a TACACS server for a network that I am working on, and I
>>> am
>>> > trying to determine how to have certain users (e.g. network admins)
>>> enabled
>>> > by default once they have logged in, but certain other users (e.g.
>>> support
>>> > group) logged in as read only, and requiring them to enable manually.
>>> >
>>> > Ive seen some suggestions of using an optional av pair "brcd-role =
>>> admin"
>>> > in the TACACS config, but seems this is for VDX devices, and I am
>>> working
>>> > with ICX.
>>> >
>>> > The usual "priv-lvl = 15" that works with Cisco doesnt seem to apply,
>>> and Im
>>> > finding scant other information about how to do this other than
>>> specifying
>>> > "aaa authentication login privilege-mode", but that would have all
>>> users
>>> > enabled once they have logged in.
>>> >
>>> > My configs look like:
>>> >
>>> > aaa authentication enable default enable
>>> > aaa authentication login default tacacs+
>>> > aaa authorization commands 0 default tacacs+
>>> > aaa authorization exec default tacacs+
>>> > aaa accounting commands 0 default start-stop tacacs+
>>> > aaa accounting exec default start-stop tacacs+
>>> > aaa accounting system default start-stop tacacs+
>>> >
>>> > and on the TACACS server Ive tried:
>>> >
>>> > group = read_write {
>>> >     default service = permit
>>> >     acl = network_nets
>>> >
>>> >     service = exec {
>>> >         priv-lvl = 15
>>> >         optional brcd-role = admin
>>> >     }
>>> > }
>>> >
>>> > Or maybe the reason I cant find any information is because this just
>>> isnt
>>> > possible on a Brocade?
>>> >
>>> > Any help appreciated!
>>> >
>>> > Thanks
>>> > Tom
>>> >
>>> > _______________________________________________
>>> > foundry-nsp mailing list
>>> > [email protected]
>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
> _______________________________________________
> foundry-nsp mailing list
> [email protected]
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>

-- 

E-Mail to and from me, in connection with the transaction 
of public business, is subject to the Wyoming Public Records 
Act and may be disclosed to third parties.

_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp