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