3.0.11 Always escaping = and ,

[Arran Cudbard-Bell]

> On 29 Feb 2016, at 16:49, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Feb 29, 2016, at 3:16 PM, Peter Lambrechtsen <peter at crypt.co.nz> wrote:
>> Nope, that doesn't work either on 3.0.11 :(
> 
>  Then it's 3.1 only.

Even in v3.0.x tmpl_expand is called in a bunch of places in rlm_ldap, I guess just not for the specific filter that's being used here.

The functionality in v3.0.x was sort of hacked in for a specific purpose, in v3.1.x we integrated the code properly with the config item parser, and enabled more configuration items.

>> Unless there is some other way to have a variable that isn't a VSA in
>> Request or Control can be passed into various modules (ldap, sql, perl,
>> files) and used within those modules easily. I haven't seen a way to easily
>> do that without poking the value I want into a temp VSA.

If there's specific requirements then let us know.  The framework is there to convert any configuration item to be a polymorphic template (can be xlat, attribute ref, exec).

>> In this case I was hoping to be clever re-using a single LDAP module with
>> it's threads and set the required Variable / VSA before calling the LDAP
>> module I need. This is because I have a fairly complex structure in LDAP,
>> and have noticed an issue where having a duplicate CN in two different
>> parts of the hierarchy for various reasons on 3.0.10 caused a segfault, now
>> in 3.0.11 it just returns a fail which is fine.
> 
>  Better... just not perfect. :(

No, that's by design and is correct.  That means the filter was not specific enough and multiple LDAP objects were returned.  It is a misconfiguration of rlm_ldap/bad data in the LDAP directory.

In addition to the restriction we added support for the server side sort control.  If that's enabled the restriction on multiple objects is removed, and the first object is used.

The goal was to ensure administrators configured rlm_ldap to work in a deterministic way.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160229/89bcef25/attachment.sig>