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@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