rlm_ldap: How to filter based on specific attributes?
Hi 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? 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). 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... 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) (Somewhat similar as to what a guy asked in 2016: http://lists.freeradius.org/pipermail/freeradius-users/2016-August/084450.ht...) If all attributes are mappable to FreeRADIUS using unlang, making conditions in the post-auth section would look possible ... right? 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) Regards Mathieu
On Jul 22, 2019, at 7:05 AM, Mathieu Simon (Lists) <matsimon.lists@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.
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.
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.
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. :(
(Somewhat similar as to what a guy asked in 2016: http://lists.freeradius.org/pipermail/freeradius-users/2016-August/084450.ht...)
If all attributes are mappable to FreeRADIUS using unlang, making conditions in the post-auth section would look possible ... right?
Yes.
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". Alan DeKok.
(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@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.ht...)
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
participants (2)
-
Alan DeKok -
Mathieu Simon (Lists)