member dn fetched from first ldap_2level request are not exactly the same of the second ldap request

[gallak]

Version

We use the 6.2.32 from tarball

Installation method

installed from tarball on debian 9 server

Expected behavior

In case of a LDAP 2 level request, all the DN fetched must be the same as the DN used for the second request in order to get the e-mail address

Actual behavior

In my case I have an Active directory group with a user which contain a double space in the DN.
When I see this DN used to fetch the email address, the double space is transformed to a single space.
I saw it on log (loglevel 2)
So the real DN isn't correct and an error occurs!

Indeed, double space isn't a correct use of an ldap directory, but we could imagine that Sympa didn"t transform ldap DN

Additional information

[ikedas]

Hi @gallak,
Could you please show example: actual DNs, setting of data source and log messages?

[gallak]

NOTE I anonymized information but space are keeped
see an extract of LDAP request of the group

# extract of LDAP tree
root@vsympa4:~#  ldapsearch -o ldif-wrap=no -x -H ldap://DC1.company.com -b DC=company,DC=com "(&([email protected])(objectClass=group)(member=*))" -D [email protected] -W member
# MO-TEMO, Groupes, site1, comany, com
dn: CN=MO-TEMO,OU=Groupes,OU=site1,DC=company,DC=com
member: CN=Lemagnen Lucie,OU=STANDBY,OU=Utilisateurs,OU=site1,DC=company,DC=com
member: CN=Silveri Federica,OU=STANDBY,OU=Utilisateurs,OU=site1,DC=company,DC=com
member: CN=Risch Eva,OU=Utilisateurs,OU=site1,DC=company,DC=com
member: CN=De Oliveira Leao  Susana,OU=Utilisateurs,OU=site1,DC=company,DC=com

Extract of config file

include_ldap_2level_query
host DC1.company.com
use_tls none
attrs2 mail
ssl_version tlsv1
suffix1 DC=company,DC=com
suffix2 [attrs1]
timeout2 30
filter2 (&(objectClass=person)(mail=*))
select2 first
name ad-rqt-mo-temo
user [email protected]
scope1 sub
attrs1 member
ca_verify required
ssl_ciphers ALL
timeout1 30
filter1 (&([email protected])(objectClass=group)(member=*))
scope2 base
passwd *******************
select1 all

Extract of log sympa ( verbose = 4)

Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug2 Sympa::List::_include_users_ldap_2level() Searching on server DC1.company.com; suffix CN=Risch Eva,OU=Utilisateurs,OU=site1,DC=company,DC=com; filter (&(objectClass=person)(mail=*)); attrs: mail
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug3 Sympa::DatabaseDriver::LDAP::do_operation() Will perform operation "search"
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug2 Sympa::List::_include_users_ldap_2level() Searching on server DC1.company.com; suffix CN=De Oliveira Leao Susana,OU=Utilisateurs,OU=site1,DC=company,DC=com; filter (&(objectClass=person)(mail=*)); attrs: mail
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug3 Sympa::DatabaseDriver::LDAP::do_operation() Will perform operation "search"
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug3 Sympa::Database::connect(Sympa::DatabaseDriver::LDAP <[email protected];ca_verify=required;host=ldap://DC1.company.com;ssl_ciphers=ALL;ssl_version=tlsv1;use_tls=none>)
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug3 Sympa::DatabaseDriver::LDAP::_connect() Bound to LDAP host "ldap://DC1.company.com"
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug2 Sympa::Database::connect() Connected to Database Sympa::DatabaseDriver::LDAP <[email protected];ca_verify=required;host=ldap://DC1.company.com;ssl_ciphers=ALL;ssl_version=tlsv1;use_tls=none>
Nov 12 11:25:56 vsympa4 wwsympa[6618]: err main::#1573 > main::do_edit_list#10507 > Sympa::List::on_the_fly_sync_include#6936 > Sympa::List::sync_include#6588 > Sympa::List::_load_list_members_from_include#5818 > Sympa::List::_include_users_ldap_2level#5282 > Sympa::DatabaseDriver::LDAP::do_operation#207 Unable to perform LDAP operation: 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:#012#011'OU=Utilisateurs,OU=site1,DC=company,DC=com'
Nov 12 11:25:56 vsympa4 wwsympa[6618]: err main::#1573 > main::do_edit_list#10507 > Sympa::List::on_the_fly_sync_include#6936 > Sympa::List::sync_include#6588 > Sympa::List::_load_list_members_from_include#5818 > Sympa::List::_include_users_ldap_2level#5295 LDAP search (2nd level) failed: (32) 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best match of:#012#011'OU=Utilisateurs,OU=site1,DC=company,DC=com'
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug2 Sympa::List::_include_users_ldap_2level() Searching on server DC1.company.com; suffix CN=Roux Philippe,OU=Utilisateurs,OU=site1,DC=company,DC=com; filter (&(objectClass=person)(mail=*)); attrs: mail
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug3 Sympa::DatabaseDriver::LDAP::do_operation() Will perform operation "search"
Nov 12 11:25:56 vsympa4 wwsympa[6618]: debug2 Sympa::List::_include_users_ldap_2level() Searching on server DC1.company.com; suffix CN=Damiani Mattia,OU=STANDBY,OU=Utilisateurs,OU=site1,DC=company,DC=com; filter (&(objectClass=person)(mail=*)); attrs: mail

thanks Soji

[ikedas]

@gallak, I couldn't figure out where is "double-space". Can you explain?

[gallak]

well, my ldapsearch was done after my ldap correction .
I edit my comment for having correct information before correction.
see "member: CN=De Oliveira Leao Susana,OU=Utilisateurs,OU=site1,DC=company,DC=com"

there is double space between "Leao" and "Susana"

On the log ( which the log when the problem occurs)
There is only one space between "Leao" and "Susana"

[ikedas]

I could reproduce.

use lib qw(/usr/share/sympa/lib);
use Sympa::Database;

my $dn = 'CN=De Oliveira Leao  Susana,OU=Utilisateurs,OU=site1,DC=company,DC=com';

my $db = Sympa::Database->new('LDAP', host => 'localhost');
$db->connect;
print $db->canonical_dn($dn), "\n";

Result is:

CN=De Oliveira Leao Susana,OU=Utilisateurs,OU=site1,DC=company,DC=com

After all, this behavior looks compliant to the standard: Some other directory servers (e.g. OpenLDAP, 389 DS) also look behaviing the same.

Personally I think it would be better to modify DNs including multiple spaces instead of changing Sympa.

[gallak]

In fact the canonical_dn method mustn't modify the DN because It's the LDAP server which keep DIT integrity inside user branch and inside group. So integrity of DN must be kept on Sympa side
Today it is the "space" caracter , what about tomorrow ?

By the way, I 'm agree with you for multiple space, its better to modify it . But I think it was important to inform you about this behaviour

thanks for your time, I let you decide what to do fix or not , but I think that it should be fix because DN integrity is not kept

[ikedas]

In fact the canonical_dn method mustn't modify the DN because It's the LDAP server which keep DIT integrity inside user branch and inside group. So integrity of DN must be kept on Sympa side

Indeed, this problem occurs with DNs under a single DIT. You say that, if AD is not compliant to standard, we should talk with it in uncompliant way.

I'll investigate the way to prevent unwished canonicalization. Please wait for a while (some weeks to months).

[ikedas]

@gallak, I found solution is simple.

Could you please check if this patch will solve the problem? Thanks.