LDAP-defined huntrgroups: docs, pointers, anything?

[Jostein Fossheim]

Hello all

We are working on a setup with freeradius using freeipa's ldap-server as 
a backend for freeradius.

I have successufully expanded det LDAP-schema with radius-attributes, etc.

Users, usergroups and clients (IPs and secrets) can be defined via ldap. 
I am hoping to be able to define huntgroups as well, but I have not 
found any detailed information on how to procceed. There is this howto 
for SQL-based backends, and random searches and LLM-queries don't get me 
any further:

https://wiki.freeradius.org/guide/SQL-Huntgroup-HOWTO

I am not certain if this really is a question for the user list or the 
devel list, but I can try both.


More details:
I was hoping to use a standard memberOf in my client-definition.

CLIENT:

dn: fqdn=[NAS-NAME].[base_domain],cn=computers,cn=accounts,[base_dn]
objectClass: ieee802Device
objectClass: ipaHost
objectClass: ipaObject
objectClass: ipaService
objectClass: ipaSshGroupOfPubKeys
objectClass: ipaSshHost
objectClass: krbPrincipal
objectClass: krbPrincipalAux
objectClass: nsHost
objectClass: pkiUser
objectClass: radiusClient
objectClass: radiusProfile
objectClass: top
cn: [FQDN]
fqdn: [FQDN]
memberOf: cn=radius_huntgroup,cn=hostgroups,cn=accounts,[base_dn]
radiusClientSecret: Testing321
radiusClientIPAddress: 192.168.0.80
serverHostName: [NAS-NAME]

"HOST/HUNTGROUP":



dn: cn=radius_huntgroup,cn=hostgroups,cn=accounts,[base_dn]
objectClass: groupOfNames
objectClass: ipahostgroup
objectClass: ipaobject
objectClass: mepOriginEntry
objectClass: nestedGroup
objectClass: top
cn: radius_huntgroup
member: fqdn=[NAS-NAME].[base_domain],cn=computers,cn=accounts,[base_dn]


So basically I want one huntgroup entry, for every group defined inn:
cn=hostgroups,cn=accounts,[base_dn]

With NASes defined in:
cn=computers,cn=accounts,[base_dn]

And their relevant IP addresses:
radiusClientIPAddress: 192.168.0.80

There are some very old posts, in the mailinglist discussing similar 
topics, but I am not found anything usefull there neither.

-- 
Best Regards

Jostein Fossheim