3.0.11 Always escaping = and ,
I'm trying to set some request temporary variables that I can use further down in the flow for lookups. update request { RealmLookup := "ou=Realms" } ldap.nodeauth But when it comes to do the lookup, the = and , get escaped so it makes an invalid DN. (0) update request { (0) RealmLookup := "ou=Realms," (0) } # update request = noop rlm_ldap (ldap.nodeauth): Reserved connection (0) (0) ldap.nodeauth: EXPAND (cn=%{AuthCred}) (0) ldap.nodeauth: --> (cn=m2m) (0) ldap.nodeauth: EXPAND %{RealmLookup}ou=Proxy (0) ldap.nodeauth: --> ou\3dRealms\2cou=Proxy (0) ldap.nodeauth: Performing search in "ou\3dRealms\2cou=Proxy" with filter "(cn=m2m)", scope "sub" (0) ldap.nodeauth: Waiting for search result... (0) ldap.nodeauth: ERROR: Failed performing search: Invalid DN syntax Any way to stop the xlat from expanding the value, I've tried unescape and a number of different options without success? Or will I need to just define multiple modules with different DNs of the places I would like to search in the hierarchy.
Hi, Can I double check my understanding of these warnings on what is currently a fairly lightly used FreeRADIUS server?: Mon Mar 7 13:57:59 2016 : Warning: rlm_sql (sql): You probably need to lower "min" Mon Mar 7 13:58:59 2016 : Warning: rlm_ldap (ldap): 0 of 0 connections in use. You probably need to increase "spare" The server appears to be functioning correctly. I can decrease 'min' for SQL to zero and the warning goes away on my dev server. LDAP only appears on live. I have not changed from the default values. From the documentation and notes in the config files, I'm reading both these to say there is not sufficient traffic to keep required number of min or spare sessions open and the is not a particular problem. As load increases these warnings will probably go away. Does that assessment sound correct? We are hoping to unleash FreeRADIUS onto a larger area of our campus as we retire off NPS, so I want to double check we are not going to drop a lot of authentications as we increase load. Thanks Dave Hartburn
Hi,
The server appears to be functioning correctly. I can decrease 'min' for SQL to zero and the warning goes away on my dev server. LDAP only appears on live. I have not changed from the default values.
why would you want to go to zero? that means a new connection needs to be created just to deal witha fresh new auth. just set the lifetime to 0 so the server doesnt keep throwing away the connections after the timeout (1 minute). then you can have usual count of spares/min/max alan
Thanks Alan, I will try that. Otherwise do you think the errors (and the LDAP) one look fine? Dave On 07/03/16 14:22, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
The server appears to be functioning correctly. I can decrease 'min' for SQL to zero and the warning goes away on my dev server. LDAP only appears on live. I have not changed from the default values.
why would you want to go to zero? that means a new connection needs to be created just to deal witha fresh new auth.
just set the lifetime to 0 so the server doesnt keep throwing away the connections after the timeout (1 minute). then you can have usual count of spares/min/max
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 29, 2016, at 4:45 AM, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
I'm trying to set some request temporary variables that I can use further down in the flow for lookups.
update request { RealmLookup := "ou=Realms" } ldap.nodeauth
But when it comes to do the lookup, the = and , get escaped so it makes an invalid DN.
Yes. The server escapes characters which are special to LDAP.
Any way to stop the xlat from expanding the value, I've tried unescape and a number of different options without success?
Not really. For that to work, we would need to add a "tainted" flag like Perl. Anything from the network is tainted, and requires escaping. Anything from the configuration files is OK, and doesn't require escaping. That's... not trivial.
Or will I need to just define multiple modules with different DNs of the places I would like to search in the hierarchy.
For now, yes. Alan DeKok.
Any way to stop the xlat from expanding the value, I've tried unescape and a number of different options without success?
Yes, create the entire DN as the value of an attribute and use &<attribute> (with no quotes) as the configuration item in the LDAP module. String escaping is (and can only be) applied to xlat expansions. The taint functionality Alan described would be useful for making this safer. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Tue, Mar 1, 2016 at 5:02 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
Any way to stop the xlat from expanding the value, I've tried unescape and a number of different options without success?
Yes, create the entire DN as the value of an attribute and use &<attribute> (with no quotes) as the configuration item in the LDAP module.
Nope, that doesn't work either on 3.0.11 :( (0) update request { (0) TNZ-BaseDN := "ou=Realms,ou=Proxy,o=Identities" (0) } # update request = noop rlm_ldap (ldap.nodeauth): Reserved connection (0) (0) ldap.nodeauth: EXPAND (cn=%{Realm}) (0) ldap.nodeauth: --> (cn=m2m) (0) ldap.nodeauth: Performing search in "&TNZ-BaseDN" with filter "(cn=m2m)", scope "sub" (0) ldap.nodeauth: Waiting for search result... (0) ldap.nodeauth: ERROR: Failed performing search: Invalid DN syntax rlm_ldap (ldap.nodeauth): Released connection (0)
String escaping is (and can only be) applied to xlat expansions.
The taint functionality Alan described would be useful for making this safer.
I've used custom defined VSAs in either the request or control as variables that get leveraged but modules further down the logic path in the code. 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. 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. So if I could set the base DN to only look into the applicable OU then I wouldn't need multiple modules depending on the user type. I had hoped to have in the LDAP module: base_dn = "%{TNZ-BaseDN}ou=Proxy,o=identities" And then if I needed to set any value for the specific Base DN I needed I would just update request TNZ-BaseDN and set it to what I want. This works for me as the value doesn't need to be escaped base_dn = "ou=%{TNZ-BaseDN},ou=Proxy,o=identities" But means I always need to have the BaseDN set to something and I can't leverage some of the hierarchy I have already built and may need to redesign some of my LDAP structure. No biggie, just a slight change to my design.
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.
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.
Yeah, that's a problem.
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. :( Alan DeKok.
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
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
David Hartburn -
Peter Lambrechtsen