Ldap Huntgroup 'Reject' issue

[Kaya Saman]

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: 
http://www-public.imtbs-tsp.eu/~gardie/LDAP/Classes/Attributes-L.html


By doing:


authorize {

         update request {
                 Huntgroup-Name ="%{ldap:ldap:///<ldap 
path>?l?sub?cn=%{Packet-Src-IP-Address}}"


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,


Kaya