rlm_ldap: How to filter based on specific attributes?

[Mathieu Simon (Lists)]

(Excuses for the direct reply to Alan, sent again to the list)

Hi Alan

Thank you for your precise feedback, definitely helped me to better
understand where I am and have to poke with the stick.

Am 22.07.2019 um 13:12 schrieb Alan DeKok:
> On Jul 22, 2019, at 7:05 AM, Mathieu Simon (Lists)
<matsimon.lists at simweb.ch> wrote:
>> I have an (OpenLDAP-based) directory that sets a specific attribute
>> (univentionNetworkAccess) on either the user or the group based on which
>> network Access is being granted. (1 means you are permitted, 0 or access
>> of that attribtue indicates no access)
>>
>> I think this is where using access_attribute wouldn't work, as it is
>> only defined in the users section but not groups - right?
>
>   Yes.
Thanks
>
>> Additionnaly access should also only be granted if certain other
>> Attributes have specific values (such as sambaAcctFlags, meaning if a
>> user is locked or disabled).
>
>   Which likely means custom policies.
Hmm, which can become quite complex, hmm...
>
>> I'm looking into where this could be configured in the most meaningful
>> way without adding to many chunks of custom logic to the default
>> configuration... as in my experience staying close to the default config
>> usually helps avoiding stupid errors...
>
>   Custom policies can be complex.   Debugging complex systems is hard.
As I learned in other cases to, but hey it is possible if you have the
need to actually do it, I hope I won't.
>
>> So far I've thought about mapping these attributes from LDAP to FR and
>> then using unlang statements in post-auth for example to check for each
>> condition.
>>
>> Q: How could I map attributes from LDAP groups to FreeRADIUS?
>> (I've only ever done this with user attributes)
>
>   In v3, it's a little complex.  In (coming some time soon) v4, it's a
"map" command.
>
Ah, now that look interesting indeed! Without you mentioning it here I
wouldn't have been able to locate it other than with the 2 lines in v4's
doc/ChangeLog. Definitely something worth mentioning prominentely IMO.

As of now "map" is currently not mentioned in v4's unlang(5), but what
about an actualy example in doc/unlang - where would that be preferred
in your oppinion?

I do plan on looking at v4 anyway even more so now.

>> (Somewhat similar as to what a guy asked in 2016:
>>
http://lists.freeradius.org/pipermail/freeradius-users/2016-August/084450.html)
>>
>> If all attributes are mappable to FreeRADIUS using unlang, making
>> conditions in the post-auth section would look possible ... right?
>
>   Yes.
Based on the previous answer more like a "technically yes, but"...
>
>> Or would it be better to modify the LDAP "filter =" statemens of the
>> ldap module in the user{ } and group{ } sections with the required
>> attributes ? (likely ending up in somewhat clunky LDAP queries)
>
>   That will be the simplest in v3.  The LDAP server will parse and
apply the filters quickly.  It will be more work to copy the data to
FreeRADIUS, and then implement the policies in "unlang".
It looked like that would be the case, but wasn't certain, thanks!
I will definitely explore that route.

-- Mathieu