[tac_plus] Configuring a/v pair expected by Brocade VDX switch

[Daniel Schmidt]

I've never had this trouble you speak of with Brocade, but then again I
have only used the CER, CES & FCX.  The config I posed on tacacs.org
seemed to work fine.

Also, users CAN be members of multiple groups, you just have to write an
authorization script.  Or, just use my do_auth.py script from tacacs.org -
several people have told me it works well.  Tac_plus, I would argue, is
more flexible than Cisco's solution.

I'm working on key replacement with do_auth - what is your issue with
Nexus?  As for brcd-role, if you are willing to do try do_auth and turn on
the debug, I should easily be able to add something for a certain IP range
that strips the pairs you don't want and appends the pairs you do.

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
Sent: Friday, September 30, 2011 3:43 PM
To: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX
switch

On Fri, 30 Sep 2011 14:14:03 -0700
Jathan McCollum <jathan at gmail.com> wrote:

> Hey John, thanks for the reply. That's a good suggestion that I'll
> tuck away for future reference.
>
> I actually tracked down access to the Brocade support knowledge base
> and found a document someone had posted using Cisco ASA.
>
> And it is:
>
> brcd-role = <role>
>
> So my group config would be:
>
> group = admin {
>     default service = permit
>     service = exec {
>         priv-lvl = 15
>         brcd-role = admin
>     }
> }
>
> However, sharing that with Cisco devices causes them to be unhappy
> and fail authorization. I tried prepending the "optional" keyword
> e.g. "optional brcd-role = admin", which makes Cisco devices happy
> again, but breaks it on the Brocade.
>
> So... almost there, but still missing something.


Hi Jathan,

I had a very similar issue getting my Cisco and Nexus kit to work
together. Short answer is I couldn't get them to work together.

The solution I opted for was to run two instances of tac_plus, the
original on port 49 for Cisco and the second on port 50 for Nexus, and
keep the configs entirely separate. This works for me and is probably
more intuitive than trying to express the same thing in a single config
file.

One of the shortcomings of tac_plus in it's current form is how
inflexible it can be. Users can be a member of only one group, which is
a member of only one group etc. Freeradius has a concept of "vhosts"
which would be insanely useful on tac_plus, but there is no comparable
feature. You seem to have run into this.

I'm not complaining (for the asking price of free tac_plus is a great
product) and until I start submitting patches I have very little
street-cred. In the meantime I accept that sometimes we have to do
things in unusual ways (like run two daemons) to get what we want.



>
> On Fri, Sep 30, 2011 at 1:59 PM, john heasley <heas at shrubbery.net>
> wrote:
>
> > Fri, Sep 30, 2011 at 01:39:32PM -0700, Jathan McCollum:
> > > The documentation indicates the device is expecting the server to
> > > send an a/v pair that specifies the authenticated user's role. I
> > > assume the value would be "admin" in this case. The problem is
> > > that nowhere in the documentation so far have I seen what
> > > attribute the device is expecting. There may also be a unique
> > > service type (again similar to JUNOS' "junos-exec") that is being
> > > expected.
> > >
> > > So... After all that background, anyone had experience with this
> > > platform and gotten it working successfully w/ tac_plus?
> >
> > none, but some devices send the av pairs they have when they perform
> > authen and/or author.  if you enable the appropriate debugging
> > knobs, it might reveal it to you.
> >
> > or, take the image that you load on the box, uncompress it, unzip
> > it or whatever their packaging method is, then run strings(1) on it
> > and look for strings that might be related to authorization.  then
> > send a bomb to brocade offices.
> >
>
>
>



-- 
Alan McKinnnon
alan.mckinnon at gmail.com
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus