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

Tue Oct 4 13:59:09 UTC 2011

My environment sounds eerily similar to Alan's. My only real means of
testing are in the lab just for the mere sake of deployment. The lab
requires no deployment and if it goes down or breaks for any reason, only
the lab gremlins notice.

Especially as I'm also a big nut for Python, I definitely want to try it
out. Sooner than later.

On Mon, Oct 3, 2011 at 1:45 PM, Daniel Schmidt <daniel.schmidt at wyo.gov>wrote:

> A test user & new group would not interfere with any current operation and
> the compiled python code runs quite fast.  I would imagine it could be
> exactly what you need.  However, I suppose we all understand the "It
> works, don't touch it!" mentality.  I suppose I will have to get some
> 5000's up & running to test with.
>
> -----Original Message-----
> From: tac_plus-bounces at shrubbery.net
> [mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
> Sent: Monday, October 03, 2011 12:12 PM
> Cc: tac_plus at shrubbery.net
> Subject: Re: [tac_plus] Configuring a/v pair expected by Brocade VDX
> switch
>
> On Mon, 3 Oct 2011 09:34:45 -0600
> 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.
>
> Hi Daniel,
>
> Yes, I'm aware of your script but I'm not willing to risk deploying it.
> Nothing to do with code quality you understand, I'm getting 1.5 million
> connections a day on a slow day and the only place I can test that for
> real is in production. My Change Manager would murder me if anything
> went wrong and I can't begin to calculate if I can cope with 50-75
> python scripts spawned a second when things get busy.
>
> And that's just the PE devices. There's a completely separate system
> for CE devices (the current bane of my life...)
>
> > 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.
>
> The main issue with Nexus is that Tacacs support is not mature on those
> devices (5k & 7k), there are just too many edge cases and too many open
> support cases with Cisco from our NetOps guys about them.
>
> As a device, the 5k's work great, we just couldn't get them to co-exist
> on the same tac_plus daemon with our wildly wonderful RealWorld(tm)
> Cisco network. Some days I feel we have at least one of every piece of
> hardware and software version Cisco ever shipped live on the network
> needing to be supported.
>
> IIRC correctly, the thing that truly made NetOps give up was "conf t" -
> our Support guys must have it to get work done on Cisco and must not be
> able to use it on Nexus otherwise things break badly.
>
> We settled for local roles on the nexus devices and doing
> authentication and accounting on tacacs. This works well for us and the
> config can be reasonably easily understood by both teams (Services and
> NetOps).
>
> I see little scope to use your script in my setup due to size and
> complexity, but please don't stop developing on it. I'm sure the vast
> majority of readers here would find it very useful indeed.
>
>
>
>
> >
> > -----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/20111004/170049e0/attachment.html>