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

Tue Oct 25 13:17:23 UTC 2011

Has anybody had any success passing a role as a tac_key?  So far, all I
see is that the nexus sends the same pairs, every time.  Any config
exampled would be appreciated.

-----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
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.