Problem with expansion of %{Ldap-UserDn} containing UTF-8 (cf. Bug #411)

[Enrik Berkhan]

Hi,

there is a problem at least with LDAP group compares when Ldap-UserDn 
contains UTF-8 which seems not to be uncommon nowadays :) (see Bug #411)

I have a setup where I use Active Directory for authorization via 
groupmembership_filter. Assume the following:

basedn = "dc=example,dc=com"
filter = "(userPrincipalName=%{Stripped-User-Name})"
base_filter = "(objectclass=user)"

groupmembership_filter = "(&(objectClass=group)(member=%{Ldap-UserDn}))"


users file:

DEFAULT ldap-group == 
"CN=allow-members-of-this-group,OU=Groups,DC=example,DC=com"


The entry in the users file triggers the LDAP group compare function, 
which in turn first searches for the user (assume Ldap-UserDn has not 
been set before) and then does a second search using the group DN as 
base DN and groupmembership_filter as filter.

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.

1. How can this issue be solved for Ldap-UserDn? Or does a solution 
already exists that I have overlooked?

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 ...

Thanks for any ideas.

Enrik