Mailing List Archive

AAA, TACACS, some users enabled on login, others not
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
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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/FI_08030_SECURITY/GUID-A2449097-2DA4-4CD1-B2DA-C531D7A90587.html
>
> --
> Eldon
>
> On Fri, Nov 4, 2016 at 5:26 AM, Tom Storey <tom@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@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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@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@puck.nether.net
>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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@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 <tom@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@puck.nether.net
>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>
>>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@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.
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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@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@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 <tom@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@puck.nether.net
>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>
>>>
>>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@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.
>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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@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@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@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 <tom@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@puck.nether.net
>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp@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.
>>
>
>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
Send tac_plus.conf & aaa config

On Wed, Nov 16, 2016 at 5:09 AM, Tom Storey <tom@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@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@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@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@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 <tom@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@puck.nether.net
>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp@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.
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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" <tom@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@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@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@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@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@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@puck.nether.net
>>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp@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.
>>>
>>
>>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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/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" <tom@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@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@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@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@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@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@puck.nether.net
>>>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> foundry-nsp mailing list
>>>>> foundry-nsp@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@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.
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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/
>> 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" <tom@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@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@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@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@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@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@puck.nether.net
>>>>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> foundry-nsp mailing list
>>>>>> foundry-nsp@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@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.
>
Re: AAA, TACACS, some users enabled on login, others not [ In reply to ]
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@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@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@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@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@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@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@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@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@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@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@puck.nether.net
>>>>>>>>> > http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> foundry-nsp mailing list
>>>>>>> foundry-nsp@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@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.