Ldap Huntgroup 'Reject' issue

Kaya Saman kayasaman at optiplex-networks.com
Wed Nov 25 22:45:37 CET 2020

Many thanks Alan!

On 2020-11-25 20:48, Alan DeKok wrote:
> On Nov 25, 2020, at 3:12 PM, Kaya Saman via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:

>> The Inner-tunnel file contains this, it's slightly different from the 'Outer' tunnel due to various matching issues I found when there are multiple 'l' values attached to the NAS lookup in ldap -
>> To clarify what I mean is that example:- a Wireless Controller has Huntgroup2, Huntgroup3 and Huntgroup4 set in the 'l' value under different ldap paths, so if it matches <ldap path 3> then look the user up and authenticate
>    I don't know what you mean by "set in the l value".  That's not a standard terminology.

I'm going to study and test your advise now so I'll get back later if 
things don't work, which is a high probability as I'm quite confused now :-S

By 'l' value I meant the LocalityName attribute in ldap - for reference: 

By doing:

authorize {

         update request {
                 Huntgroup-Name ="%{ldap:ldap:///<ldap 

The Huntgroup-Name should equal the ?l? portion within the ldap path 
given before the Auth := Accept/Reject decision is made.

I think this is where I am getting myself confused a little and probably 
finding it difficult to explain in addition??

In short I want to test the Huntgroup-Name against the ldap 
LocaliltyName attribute which should match. If they don't then send the 
Auth := Reject.

I'm not sure if there are any examples of this to help me understand 
better how things work and how they should be implemented?

>> - if the huntgroup does not match then try a different path using attributes based on the unlang operators:
>    If you're not using the huntgroups file, don't use Huntgroup-Name.  If you want to set Huntgroup-Name to something, then you're using it wrong.  Use another attribute.
>> This is a partial output from radiusd -X - the user is not found in any of the administrative ldap paths and then hits line 314 which is the line "DEFAULT Auth-Type := Reject" in the authorize file, but then it proceeds to the ldap module and is granted access:
>    Probably because the Huntgrop-Name comparisons are checking the ungroups file, and not the extra "Huntrgroup-Name" things you added.
>> What needs to be done in order for FR to make a decision based on the evaluation of the authorize file and 'accept' or 'reject' accordingly?
>    FreeRADIUS already makes a decision based on evaluating the "authorize" file.
>> Currently I'm going through the 'unlang' and 'SQL-Huntgroup-Howto' in the FR Wiki but I'm unable to work this one out. Perhaps a 'Post-auth' statement is necessary? - currently this is in the 'inner-tunnel' file
>    You don't need to move things to a different section.  Instead, stop re-using existing attributes for different functionality.
>    I'd also say to start with a simple example.  Add a local attribute in raddb/dictionary, and use that.  Maybe even move the "users" file checks to "unlang".
>    Alan DeKok.

Best Regards,


More information about the Freeradius-Users mailing list