On 30 Aug 2011, at 18:21, Morty wrote:
> I have a variety of Cisco devices that require mutually incompatible
> values in a certain RADIUS attribute, Cisco-AVPair. The way I have
> dealt with this in the past is with huntgroups -- I assign our
> engineer group on huntgroup1 to have Cisco-AVPair set to
> shell:roles=network-admin, while by default, the engineer group gets
> shell:priv-lvl=15. So far, so good. Problem is that we have another
> new kind of Cisco device that achieves engineer read-write with
> Cisco-AVPair set to shell:roles*admin. I figured that I would just
> set up another huntgroup, but this device apparently also doesn't set
> NAS-IP-Address or NAS-Identifier, so the usual huntgroup mechanism
> doesn't work.
Then its not in compliance with RFC 2865 and you should go beat Cisco up about
it.
An Access-Request SHOULD contain a User-Name attribute. It MUST
contain either a NAS-IP-Address attribute or a NAS-Identifier
attribute (or both).
How can vendors screw up such basic stuff.
Can't you include both AVPs with the += operator? Or does the Cisco device
throw a hissy fit?
>
> My production environment currently uses Cistron. But I'm planning to
> switch to freeradius. Unfortunately, it looks to me like the same
> issue applies to freeradius.
>
> Help? Is there any way to make a distinction between devices in the
> config without using huntgroups based on NAS-IP-Address or
> NAS-Identifier?
>
If the packets aren't going through a proxy or NAT then you can use
Packet-Src-IP-Address instead of NAS-IP-Address.
>
> [I sent a very similar message to the cistron mailing list, BTW. I'm
> looking for a solution for either program.]
Oh come on the Cistron page hasn't received any love since 06, you know you
want to switch :)
Arran Cudbard-Bell
a.cudba...@freeradius.org
RADIUS - Half the complexity of Diameter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
