rlm_ldap: How to filter based on specific attributes?

Alan DeKok aland at deployingradius.com
Tue Jul 23 13:34:00 CEST 2019


On Jul 23, 2019, at 3:37 AM, Mathieu Simon (Lists) <matsimon.lists at 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.




More information about the Freeradius-Users mailing list