LDAP-defined huntrgroups: docs, pointers, anything?

[Jostein Fossheim]

On 2025-03-06 10:06, Jostein Fossheim via Freeradius-Users wrote:
> On 2025-03-05 23:31, Jostein Fossheim via Freeradius-Users wrote:
>>
>> On 05/03/2025 20:34, Alan DeKok wrote:
>>> On Mar 5, 2025, at 1:59 PM, Jostein Fossheim 
>>> <jfossheim at skyfritt.net> wrote:
>>>> Did some basic tests from the command line:
>>>>
>>>> I have defined one NAS/client in our lab-setup with IP 
>>>> 172.17.10.112, which is a member of two "huntgroups" (hostgroups in 
>>>> FreeIPA), and I can either get them in one query or two queries. 
>>>> Like this:
>>>>
>>>> # One query:
>>>> $ ldapsearch -LLLQ -o ldif_wrap=no 
>>>> "(radiusClientIPAddress=172.17.10.112)" memberOf | grep -v "^dn: "
>>>> memberOf: 
>>>> cn=radius_huntgroup,cn=hostgroups,cn=accounts,dc=lab,dc=skyfritt,dc=net 
>>>>
>>>> memberOf: cn=radius_huntgroup,cn=ng,cn=alt,dc=lab,dc=skyfritt,dc=net
>>>> memberOf: 
>>>> cn=radius_second_huntgroup,cn=hostgroups,cn=accounts,dc=lab,dc=skyfritt,dc=net
>>>> memberOf: 
>>>> cn=radius_second_huntgroup,cn=ng,cn=alt,dc=lab,dc=skyfritt,dc=net
>>>>
>>>> # Two queries:
>>>> $ "ldapsearch -LLLQ -o ldif_wrap=no 
>>>> "(radiusClientIPAddress=172.17.10.112)" fqdn | grep -v "^dn: "
>>>> fqdn: valkyrie3.lab.skyfritt.net
>>>>
>>>> $ ldapsearch -LLLQ -o ldif_wrap=no 
>>>> "(member=*valkyrie3.lab.skyfritt.net*)" cn | grep -v "^dn: "
>>>> cn: radius_huntgroup
>>>> cn: radius_second_huntgroup
>>>>
>>>> So huntgroups should be doable, after the model form the SQL-howto.
>>>    That's good news!
>> I see that the exact structure/syntax for doing ldap-queries in 
>> unlang is somewhat different from the ldapsearch tool, but goes via 
>> standard ldap-urls, like this bellow. I tested with a reply-message 
>> in the post-auth section that queries for my full name:
>>
>> update reply {
>>     Reply-Message += "Welcome to our realm 
>> %{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?displayName?sub?(uid=%{User-Name})}"
>>
>> }
>
> Almost there!
>
> I am able to sucessfully add the first HuntGroup from my query, so if 
> a NAS is only member of one ldap-group, everything seems to be ok now, 
> but I want multiple groups, if posible. I can do something like this:
>
>         update request {
>               Huntgroup-Name := 
> "%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?cn?sub?(member=*valkyrie3.lab.skyfritt.net*)}"
>               Huntgroup-Name += 
> "%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?cn?sub?(&(member=*valkyrie3.lab.skyfritt.net*)(!(cn=%{Huntgroup-Name})))}"
>         }
>
> Then Huntgroup-Name will contain both radius_huntgroup and 
> radius_second_huntgroup, but I am uncertain on how to expand this 
> trick into handeling more groups.
>
> The ldap-query seems only to report back one group, but it should 
> report back two. Can I handle this with a foreach, or is the 
> query-functionality limited here?
>

The following code handles HuntGroups in my setup, I have still not 
handled multiple HuntGroups, which should be doable, but I have the 
trick for showing two groups.

         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}*)}"
               Huntgroup-Name += 
"%{ldap:ldap:///cn=accounts,dc=lab,dc=skyfritt,dc=net?cn?sub?(&(member=*%{Tmp-String-0}*)(!(cn=%{Huntgroup-Name})))}"
         }

         update reply {
               Reply-Message += "NAS-IP-Address is: %{NAS-IP-Address}"
         }

         update reply {
             Reply-Message += "NAS-FQDN is: %{Tmp-String-0}"
         }

         foreach &Huntgroup-Name {
               update reply {
                     Reply-Message += "NAS is a member of Huntgroup: 
%{Foreach-Variable-0}"
               }
         }

I probably need some help with my query, from someone with more 
unlang-experience.



-- 
Best Regards,

Jostein Fossheim