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.