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

Daniel Schmidt daniel.schmidt at wyo.gov
Fri Nov 18 14:35:39 EST 2016 

It does work.  Order and number of pairs matter - put priv-lvl first.

On Fri, Nov 18, 2016 at 2:41 AM, Tom Storey <tom at snnap.net> wrote:

> 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 <daniel.schmidt at wyo.gov>
> 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 <tom at snnap.net> 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/F
>>> I_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html
>>>
>>> Tom
>>>
>>>
>>> On 16 November 2016 at 15:01, Eldon Koyle <ekoyle+puck.nether.net at 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" <tom at snnap.net> 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 <daniel.schmidt at wyo.gov>
>>>>> 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 <
>>>>>> ekoyle+puck.nether.net at gmail.com> 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" <tom at snnap.net> 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 at gmail.com> 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 <tom at snnap.net> 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
>>>>>>>>> > foundry-nsp at puck.nether.net
>>>>>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> foundry-nsp mailing list
>>>>>>> foundry-nsp at puck.nether.net
>>>>>>> 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
>>> foundry-nsp at puck.nether.net
>>> 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.
>>
>
>

-- 

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20161118/08cd376c/attachment.html>

More information about the foundry-nsp mailing list