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

[Jathan McCollum]

Thanks Dan, I will give do_auth a shot in the lab and report back sometime
between that time and eterinity.  :)

On Mon, Oct 3, 2011 at 8:34 AM, Daniel Schmidt <daniel.schmidt at wyo.gov>wrote:

> 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
> _______________________________________________
> tac_plus mailing list
> tac_plus at shrubbery.net
> http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
>



-- 
Jathan.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.shrubbery.net/pipermail/tac_plus/attachments/20111003/eff0b8ee/attachment.html>