Ldap Huntgroup 'Reject' issue

[Alan DeKok]

On Nov 25, 2020, at 3:12 PM, Kaya Saman via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> I've just noticed that there is a little difference in functionality between FR 2.x and 3.21. The config I have, worked fine in v2 but now in v3 it is not doing what I intend.

  There's a bunch of differences, mostly minor.   See raddb/README.rst in v3 for a complete upgrade guide, and a list of what changed.

> I'm using an Openldap backend which consists of users and groups and I would like to restrict access based on the user-group association in ldap.
> 
> eg. any user belonging to the Guest group should only be given authenticated access to guest areas (currently restricted to Wifi) while 'normal' users should get standard Wifi access but not access to NAS config shells etc; admin group gets all access with no restrictions
> 
> 
> My current FR config takes the Huntgroup name and looks at the 'l' values in ldap for a match. This is the tail end of my Authorize file: *I've used <> to indicate comments  and it is not part of the config file*

  OK... there usually isn't a lot of point in posting the config.  But whatever.

> The Outer-tunnel (default) file contains the following under the Authorize section:
> 
> authorize {
> 
>         update request {
>                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 1>?l?sub?cn=%{Packet-Src-IP-Address}}"

  Why?  Huntgroups are matched in the huntgroups file.

  If you want to define your own meaning for attributes, just define your own attributes.  See raddb/dictionary for examples.

  Don't over-load the existing attributes.  Things like Huntgroup-Name do *matching*.  It's not really appropriate to set a value for them.

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

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