Re: rlm_ldap: How to filter based on specific attributes?
Hi Alan Concerning mapping attributes of an LDAP group (not evaluating group memberships), I have made and attempt but failed so far. Mapping an attribute from a LDAP user to a FreeRADIUS attribute is very simple in and straightforward: - Add a custom myattrib to dictionary - Extend the mapping of LDAP attribute control:<myattrib> in the update{ } section of mods-available/ldap - Add a simple if { } check for control:<myattrib> in post-auth of sites-enabled/<yourserver> and be happy :-) The problem is that in that particular directory (whether I like it or not...) the relevant permission can be set for the user but it can also be set on a group is a member of. Thus both LDAP filters would need to yield an ACCESS-ACCEPT: (&(objectClass=posixGroup)(memberUid=bob)(univentionNetworkAccess=1)) OR (&(objectClass=posixUser)(uid=bob)(univentionNetworkAccess=1)) If I configure both user and group filter, the attribute would be required on both the user and the group for example. Instead said permission attribute, this could also be a VLAN ID attribute that is set at the level of an LDAP group. I've also tried searching if others have attempted mapping VLANs based on LDAP attributes, not group memberships alone, but it doesn't seem so. Creative use of search engines and an attempted areading rlm_ldap's source code hasn't brought a step ahead yet. - Maybe I'm looking at it the wrong way? Sorry... Am 23.07.2019 um 04:29 schrieb Alan DeKok:
On Jul 22, 2019, at 4:37 PM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Thank you for your precise feedback, definitely helped me to better understand where I am and have to poke with the stick.
You're welcome. FreeRADIUS is a complex system, even without adding LDAP.
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.
The doc/ChangeLog for v4 says little more than "it's version 4". Yes, but not much yet about its usage, nonetheless very exciting to hear about what is coming with v4. [...]
It should be listed in "man unlang". And in doc/unlang/map.adoc OK, neither is present yet, but as you mentioned: v4 is WiP, I hope to give a look at v4, I can't promise providing docs but I'd like to if time allows.
[...]
I do plan on looking at v4 anyway even more so now. :)
It's stable. There are large parts which work. But also large parts with "here be dragons".
We're not comfortable releasing an official v4 until (a) there are no "gotchas" with features that sort of almost work, and (b) everything is fully documented.
Perfect: Again, your work and the work of the other main contributors is highly appreciated. -- Mathieu
On Jul 23, 2019, at 3:37 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
Concerning mapping attributes of an LDAP group (not evaluating group memberships), I have made and attempt but failed so far.
Mapping an attribute from a LDAP user to a FreeRADIUS attribute is very simple in and straightforward: - Add a custom myattrib to dictionary - Extend the mapping of LDAP attribute control:<myattrib> in the update{ } section of mods-available/ldap - Add a simple if { } check for control:<myattrib> in post-auth of sites-enabled/<yourserver> and be happy :-)
Good...
The problem is that in that particular directory (whether I like it or not...) the relevant permission can be set for the user but it can also be set on a group is a member of.
Yes. There's a balance between making the default configuration simple, and making it powerful. In v4 we're leaning more towards simple and powerful. So the simple things become simpler, and the complex things become more complex. But they're still a collection of simple pieces.
Thus both LDAP filters would need to yield an ACCESS-ACCEPT:
(&(objectClass=posixGroup)(memberUid=bob)(univentionNetworkAccess=1)) OR (&(objectClass=posixUser)(uid=bob)(univentionNetworkAccess=1))
If I configure both user and group filter, the attribute would be required on both the user and the group for example.
Yeah, that's imperfect.
Instead said permission attribute, this could also be a VLAN ID attribute that is set at the level of an LDAP group. I've also tried searching if others have attempted mapping VLANs based on LDAP attributes, not group memberships alone, but it doesn't seem so.
Creative use of search engines and an attempted areading rlm_ldap's source code hasn't brought a step ahead yet. - Maybe I'm looking at it the wrong way? Sorry...
The LDAP module is designed to have attributes at the user level, not the group level.
Yes, but not much yet about its usage, nonetheless very exciting to hear about what is coming with v4.
Lots and lots of new things. Many, many, better features.
OK, neither is present yet, but as you mentioned: v4 is WiP, I hope to give a look at v4, I can't promise providing docs but I'd like to if time allows.
Sure. If you're willing to try v4, the "map" syntax is not hard. It's like an "update" statement, but the RHS is taken from the source LDAP / SQL / whatever. Only the LHS is RADIUS attributes. map ldap "ldap query" { Tunnel-Private-Group-Id := ldap_attribute ... } But to use v4, you'll have to change large amounts of your configuration. See: https://github.com/FreeRADIUS/freeradius-server/tree/master/doc/upgrade
Perfect: Again, your work and the work of the other main contributors is highly appreciated.
Thanks. Alan DeKok.
On Jul 23, 2019, at 3:37 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
It should be listed in "man unlang". And in doc/unlang/map.adoc OK, neither is present yet, but as you mentioned: v4 is WiP, I hope to give a look at v4, I can't promise providing docs but I'd like to if time allows.
https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/unlang/map.a... We're working on adding "map" documentation for each module. Alan DeKok.
Hi Alan Concerning the LDAP module in v3:
The LDAP module is designed to have attributes at the user level, not the group level. That is somewhat sad to read but you confirmed what I feared based on my previous research. Now I know that I don't need to bang my head against a solid door. ;-)
The current way I'm exploring (on low priority) is either using rlm_python as the vendor provides some Python libraries that mostly ease things up how to integrated with his OpenLDAP and schema extensions. In another case using rlm_exec using mods-available/echo or exec might be possible in order to run additional checks that are not doable with unlang yet. Am 24.07.2019 um 13:31 schrieb Alan DeKok:
On Jul 23, 2019, at 3:37 AM, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
It should be listed in "man unlang". And in doc/unlang/map.adoc OK, neither is present yet, but as you mentioned: v4 is WiP, I hope to give a look at v4, I can't promise providing docs but I'd like to if time allows.
https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/unlang/map.a...
We're working on adding "map" documentation for each module. Sweet, much appreciated.
-- Mathieu
participants (2)
-
Alan DeKok -
Mathieu Simon (Lists)