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

Yeah but as per the article I linked, it *should* do some translation to
derive the privlvl from some other AV pair.

Will investigate the do_auth route as we have a multi-vendor environment at
play.

On 17 November 2016 at 18:32, Daniel Schmidt <[email protected]> wrote:

> Yeah.... I don' t think that is going to work.  I'm pretty sure you can
> only have one priv-lvl.  I can't remember if Brocade is smart enough to
> figure it out, I'm pretty sure Cisco is not.  That's why Jathan and I wrote
> do_auth, so you can swap that tac_pair based on what IP it comes from.  If
> you don't have any cisco, just pull the priv-lvl out.  If not, consider
> do_auth.
>
> On Thu, Nov 17, 2016 at 6:39 AM, Tom Storey <[email protected]> wrote:
>
>> Yeah, foundry-privlvl and brocade-privlvl did nothing. Also per my
>> original email I seemed to try brcd-role.
>>
>> aaa authentication enable implicit-user
>> aaa authentication login default tacacs+ local
>> aaa authorization commands 0 default tacacs+ none
>> 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+
>> !
>>
>> group = read_write {
>>     default service = permit
>>     acl = venus_nets
>>
>>     service = exec {
>>         idletime = 30
>>         priv-lvl = 15
>>         <insert other priv level>
>>     }
>> }
>>
>> I had to add the foundry-privlvl/brocade-privlvl AVs as optional,
>> otherwise they were mandatory and would break login on things like Cisco.
>>
>> Also, as per the link below, it would seem that I shouldnt even need to
>> specify a Foundry/Brocade specific AV, because it should take the last
>> numeric AV as the privlvl, and translate Cisco-esque priv levels in to its
>> own scheme.
>>
>> http://www.brocade.com/content/html/en/configuration-guide/
>> FI_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html
>>
>> Tom
>>
>>
>> On 16 November 2016 at 15:01, Eldon Koyle <ekoyle+puck.nether.net@gmail.
>> com> wrote:
>>
>>> Did you try the foundry-privlvl one?  Also, if you are using tac_plus,
>>> you should be able to enable debug and look at the actual avp's
>>> sent/received by the server.
>>>
>>> --
>>> Eldon
>>>
>>> On Nov 16, 2016 5:09 AM, "Tom Storey" <[email protected]> wrote:
>>>
>>>> Hi Daniel,
>>>>
>>>> I hadnt tried the brocade-privlvl AV pair before, so I gave that a try,
>>>> but still that didnt seem to enable me upon login.
>>>>
>>>> Either the TACACS server isnt sending the AV pair (although I believe
>>>> it is, because if it is not made optional, then I cant login to Cisco
>>>> devices for example), or the Brocades are just ignoring them or Im just
>>>> doing something really wrong...
>>>>
>>>>
>>>> On 15 November 2016 at 17:06, Daniel Schmidt <[email protected]>
>>>> wrote:
>>>>
>>>>> 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 <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> We use foundry-privlvl = 0 for admin access.
>>>>>>>>
>>>>>>>> See also: http://www.brocade.com/content
>>>>>>>> /html/en/configuration-guide/FI_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
>>
>
>
>
> 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