Enrik Berkhan wrote:
Assume now the first search returns a user_dn containing UTF-8. The %{Ldap-UserDn} in the groupmembership_filter will then be expanded by xlat.c using \ooo (octal) for the 8bit characters. Then, the second search can not match, because the member attribute of the group contains member DNs in UTF-8, but the value to compare has been 'destroyed' by xlat.
What part of the server has destroyed that? The ldap escaping function implements the requirements of RFC 4514 for escaping LDAP strings. It doesn't mangle UTF-8 strings.
1. How can this issue be solved for Ldap-UserDn? Or does a solution already exists that I have overlooked?
I think the solution is to update src/lib/print.c to handle UTF-8 by default.
2. Is this a general issue for variable expansions handling _all_ 8bit characters as kind of 'non-printable', may be 'unsafe' characters? Remember that most query expansions like in rlm_ldap and rlm_sql have their own notion of unsafe characters and escape again ...
I think so, yes. Alan DeKok.