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

[Jathan McCollum]

Oh hell no! Brocade has been pretty good about support. I'll vomit
blood until they add support for the "optional" keyword.

jathan.

On Sep 30, 2011, at 14:43, Alan McKinnon <alan.mckinnon at gmail.com> wrote:

> 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