On 29 Feb 2016, at 16:49, Alan DeKok <aland@deployingradius.com> wrote:
On Feb 29, 2016, at 3:16 PM, Peter Lambrechtsen <peter@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2