Re: LDAP-defined huntrgroups: docs, pointers, anything?

On 2025-03-06 13:45, Alan DeKok wrote:
> On Mar 6, 2025, at 6:10 AM, Jostein Fossheim via Freeradius-Users <[email protected]> wrote:
>> My final attempt to handle up to five huntgroups per NAS:
>    Why not just search for _all_ NAS names, and return the values as a string?  You can then split the string apart in unlang.  I don't know enough about LDAP to suggest changes to the queries, but it should work in theory.  Something like "cn=*" may work.
>
>    Or, create a second LDAP module which just runs the hunt group queries.  That will result in more connections to the LDAP server, but that shouldn't be a problem.  You can then use the LDAP module 'update' section to add multiple huntgoup names.
>
>    Alan DeKok.

That is the strange part, i would assume that this would do the trick to 
get all the values:

         update request {
             Huntgroup-Name := "testgroup"
             Tmp-String-0 := 
"%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?fqdn?sub?(radiusClientIPAddress=%{NAS-IP-Address})}"
         }


         update request {
               Huntgroup-Name += 
"%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?cn?sub?(member=*%{Tmp-String-0}*)}"

         }

If I run the query via the command  line:

$ ldapsearch -LLLQ -o ldif_wrap=no -b 
"cn=accounts,dc=lab,dc=skyfritt,dc=net" 
"(radiusClientIPAddress=172.17.10.112)" fqdn | grep -v "^dn:"
fqdn: valkyrie3.lab.skyfritt.net

$ ldapsearch -LLLQ -o ldif_wrap=no -b 
"cn=accounts,dc=lab,dc=skyfritt,dc=net" 
"(member=*valkyrie3.lab.skyfritt.net*)" cn | grep -v "^dn:"
cn: radius_huntgroup
cn: radius_second_huntgroup
cn: radius_third_huntgroup
cn: radius_fourth_huntgroup
cn: radius_fifth_huntgroup

It returns this, but when I do the query above, in the 
authorize-section, i am only able to get one/the first value back, so it 
might be a limitation in the query-function.

Huntgroup-Name := 
"%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?fqdn?sub?(radiusClientIPAddress=%{NAS-IP-Address})}"

I am uncertain on how to do a better search, and I have to do a deeper 
investigation into you're second suggestion. I hope to have a solution 
ready for deployment in a couple of weeks, since both my own company and 
several customers wants this working. But it might for all practical 
purposes be enough that a NAS can be a member of five different 
huntgroups. After all I do believe that there is a limitation on one 
group per NAS, in the original implementation (but I might be wrong on 
that)

Output from radtest, which loops through the the Hountgroup-Name attribute:

Received Access-Accept Id 148 from 172.17.251.110:1812 to 
172.17.10.112:50114 length 3758
         Reply-Message = "NAS-FQDN is: valkyrie3.lab.skyfritt.net"
         Reply-Message = "NAS-IP-Address is: 172.17.10.112"
         Reply-Message = "NAS is a member of Huntgroup: radius_huntgroup"
         Reply-Message = "NAS is a member of Huntgroup: 
radius_second_huntgroup"
         Reply-Message = "NAS is a member of Huntgroup: 
radius_third_huntgroup"
         Reply-Message = "NAS is a member of Huntgroup: 
radius_fourth_huntgroup"
         Reply-Message = "NAS is a member of Huntgroup: 
radius_fifth_huntgroup"

-- 
Best Regards,

Jostein Fossheim

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html