Changes to LDAP configuration and group processing

Arran Cudbard-Bell a.cudbardb at freeradius.org
Thu Mar 28 04:46:43 CET 2013


The configuration for rlm_ldap has changed slightly.

There's now a new subsection 'user' which contains:
	* basedn (allows specification of a specific base dn for users)
	* scope (defaults to sub)
	* filter (moved from main configuration section)
	* positive_access (moved from profile)
	* access_attribute (moved from profile)

Group has three additional config items
	* basedn (allows specification of a specific base dn for groups)
	* scope (defaults to sub)
	* filter (which is combined with the membership filter, and used on its own when converting group names to DNs)
	* cacheable_name - Retrieves all group memberships as group names
	* cacheable_dn - Retrieves all group memberships as group DNs

basedn in the main config section has been left in, but will be overridden by basedn set in user or group. The default scope of user and group is "sub" which is the same as before, but can be set to one (or base, though i'm not sure why you'd do that).

The cacheable_* items if enabled, will convert all memberships to the group attribute created when the module is instantiated (LDAP-Group if no instance name is provided).

Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Waiting for bind result...
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Bind successful
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	expand: '%{Stripped-User-Name}' -> ''
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	... expanding second conditional
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	escape: 'arr2036' -> 'arr2036'
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	expand: '%{User-Name}' -> 'arr2036'
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	expand: '(uid=%{%{Stripped-User-Name}:-%{User-Name}})' -> '(uid=arr2036)'
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : 	expand: 'dc=rm-rfi,dc=com' -> 'dc=rm-rfi,dc=com'
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Performing search in 'dc=rm-rfi,dc=com' with filter '(uid=arr2036)'
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Waiting for search result...
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : User object found at DN "uid=arr2036,ou=people,dc=rm-rfi,dc=com"
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Added Ldap-Group with value "example" to control list
Wed Mar 27 17:59:27 2013 : Debug: (2) ldap : Added Ldap-Group with value "nonexistant" to control list

Wed Mar 27 17:59:28 2013 : Debug: (2) files : Searching for user in group "example"
Wed Mar 27 17:59:28 2013 : Debug: (2) files : User found. Matched cached membership

If you want to use cacheable_* the format should match the format of your check items. If you have a check item in a format thats not cached the module will fallback to querying the LDAP directory.

For those using Active Directory where all the membership information is in memberOf attributes in the user object, you will see a performance increase by turning on the cacheable_* which matches the format of those attributes, and using check items of that format, even if you don't cache any of the membership attributes.

The old code did the following:
* query to get user DN
* query to get attributes for mapping
* query to get access attributes and profile attributes (then one query per profile)
* query for every membership check
* optional edir query to retrieve password
* optional edir query to check authorisation

The new code without caching does
* query to get DN, mapping, access attributes, profile attributes (then one query per profile)
* optional edir query to retrieve password
* optional edir query to check authorisation
* query for every membership check

The new code with caching just does
* query to get DN, mapping, access attributes, profile attributes (then one query per profile), membership attributes
* optional edir query to retrieve password
* optional edir query to check authorisation

If you don't want to try out the new features then the only change required in your config is to create a user {} section and move the filter and access config items into it.

Profiles for group objects are not supported, looking at the 2.x.x code, i'm not sure they ever were. But if someone knows differently let me know, and i'll try and hack support in for them (though it'll only be for dynamic group lookups until we have nested attributes).

The module src has been split out into individual files, attrmap.c deals with mapping attributes, group.c contains the group logic, edir.c contains the edir code, ldap.c contains the main functions (rlm_ldap_bind, rlm_ldap_search, rlm_ldap_modify), and rlm_ldap.c contains the module functions.

Any patches that call libldap functions to bind, search or modify attributes will not be accepted. Any code that needs to determine the user's DN must call rlm_ldap_find_user.

Error handling has been improved. The module will now always print any error messages provided by the server, and where the server and library errors differ, print information for both. In the case of partial DN matches (due to misconfiguration) it should also print out a string showing where the match failed.

That's about all I can think of to improve the LDAP module logic, at some point the module should be split into logic and connection pool, but that can wait a while.

-Arran



More information about the Freeradius-Devel mailing list