LDAP attribute mapping

Arran Cudbard-Bell a.cudbardb at freeradius.org
Tue Oct 30 16:29:20 CET 2012

On 30 Oct 2012, at 13:00, John Dennis <jdennis at redhat.com> wrote:

> On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote:
>> Quick poll.
>> For 3.0 the ldap module will be moving away from using the
>> ldap.attrmap file and instead use a config based mapping.
>> There are a few ways we are considering for organising the mapping.
>> We can use something like the existing unlang:
>> Or something like rlm_rest  and rlm_cache:
>> It really depends on whether people are actually using the full
>> ldap.attrmap, or whether they're just pulling out one or two
>> attributes. Each approach is as efficient as the other performance
>> wise, so it comes down to which one people prefer.
>> Any thoughts?
> What I'd like to see is the individual modules converging on common behavior so there is a consistent model.

This is what's happening. We now have a common API for connections which means that managing connection pools is done in a consistant and easy to understand way.

TLS configuration is also being standardised as much as possible, though there will probably be some minor differences where libraries only expose a subset of OpenSSL configuration parameters.

> I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS.


> If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules.

With 2.0 there was an effort to maintain configuration compatibility, which limited standardisation efforts. Maintaining config compatiblity with 3.0 we don't have that constraint.

That said, discuss whether using exactly the same syntax is useful. People may get more confused and try to use other unlang statements within module configs.

> Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of the very few opportunities available to clean up.



More information about the Freeradius-Users mailing list