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.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter