Group-Name in freeradius reply item list

[Yick Xie]

Well, there are still some options for us, as documented in Cisco's
manual[1] and a related guide[2]. It seems that the solution for group
policies varies from different
providers[3](Cisco/Juniper/Huawei/etc..) just like dictionaries built
in raddb. From my perspective the attribute Class
(rfc2865#section-5.25) could be a safe choice and compatible with
Cisco's standard[1](Table C-8). If needed one day, it could be scaled
up flexibly to more complicated extend as vendor specified.

I tried to modify the RAD_GROUP_NAME to 25 in ocserv, and the match failed.
It's sure that the NAS can receive the attribute Class, which was ASCII coded.
e.g. the attribute Class was set to "10" in sql.
tshark: <field name="radius.Class" showname="Class: 3130" size="2"
pos="64" show="31:30" value="3130"/> .
in /etc/ocserv/config, config-per-group = /etc/ocserv/config-per-group/.
Under /etc/ocserv/config-per-group/, I created files named
10,3130,31:30, and no one matched. Anything else shall be configed?

[1]http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/ref_extserver.html
[2]http://resources.intenseschool.com/radius-series-part-2-anyconnect-vpn-with-radius-authentication/
[3]https://kb.swivelsecure.com/wiki/index.php/RADIUS_Groups

Regards,
Yick

2016-03-28 21:56 GMT+08:00 Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com>:
> On Fri, 2016-03-25 at 21:59 +0800, Yick Xie wrote:
>> Hi,
>>
>> I found the attribute Group-Name(1030) cannot go in the reply item
>> list, as it is mentioned in
>> /usr/local/share/freeradius/dictionary.freeradius.internal, meanwhile
>> other attributes in this list work fine such as Reply-Message. I
>> tested with radtest and tshark, and no such attribute was captured.
>> Is
>> it ignored by both tools? Or I missed something need to be configed
>> in freeradius?
>
> Indeed, that attribute cannot be send by freeradius. This is pretty
> much an experimental attribute used by ocserv as such. Do you know any
> standard attribute that could hold the group name? If there isn't any
> maybe ocserv should stop supporting the group-name at all.
>
> regards,
> Nikos
>
>