I cannot reproduce the problem.

$ ldapsearch -LLLx -D 'uid=tuser0,ou=people,dc=example,dc=com' -w tuser00 -b "uid=tuser0,ou=people,dc=example,dc=com" dn
dn: uid=tuser0,ou=People,dc=example,dc=com

$ ldapsearch -LLLx -D 'uid=TuSeR0,ou=people,dc=example,dc=com' -w tuser00 -b "uid=tuser0,ou=people,dc=example,dc=com" dn
dn: uid=tuser0,ou=People,dc=example,dc=com

What version of 389-ds-base you are running?
$ rpm -q 389-ds-base

What does this return?
$ ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=schema" -o "ldif-wrap=no" attributetypes | egrep "\<uid>"

Check the DB - perhaps it makes a difference with what case the uid or unnormalized DN value was stored in the id2entry, entryrdn, or uid indexes.

ldapsearch -LLLx -D 'uid=tuser01,cn=users,dc=XXX,dc=XXX' -w XXX -b "uid=tuser01,cn=users,dc=XXX,dc=XXX" dn

dn: uid=tuser01,cn=users,dc=XXX,dc=XXX

ldapsearch -LLLx -D 'uid=TuSeR01,cn=users,dc=XXX,dc=XXX' -w XXX -b "uid=TuSeR01,cn=users,dc=XXX,dc=XXX" dn

ldap_bind: No such object (32)
matched DN: cn=users,dc=XXX,dc=XXX

rpm -q 389-ds-base

389-ds-base-1.3.3.1-20.el7_1.x86_64

ldapsearch -LLLx -D 'cn=directory manager' -W -b "cn=schema" -o "ldif-wrap=no" attributetypes | egrep "\<uid>"

Enter LDAP Password:
attributetypes: ( 1.3.6.1.4.1.6981.11.3.9 NAME 'FTPgid' DESC 'System uid (overrides gidNumber if present)' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'Pure-FTPd' )
attributetypes: ( 1.3.6.1.4.1.6981.11.3.8 NAME 'FTPuid' DESC 'System uid (overrides uidNumber if present)' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'Pure-FTPd' )
attributetypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 4519' X-DEPRECATED 'userid' )

ldapsearch -x -D "cn=Directory Manager" -w XXX -s one -b "cn=mapping tree,cn=config"

extended LDIF

LDAPv3

base <cn=mapping tree,cn=config> with scope oneLevel

filter: (objectclass=*)

requesting: ALL

cn\3Dusers\2Cdc\3DXXX\2Cdc\3DXXX, mapping tree, config

dn: cn=cn\3Dusers\2Cdc\3DXXX\2Cdc\3DXXX,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: cn=users,dc=XXX,dc=XXX
cn: "cn=users,dc=XXXX,dc=XXX"
nsslapd-state: backend
nsslapd-parent-suffix: dc=XXX,dc=XXX
nsslapd-backend: XXX-users-20
nsslapd-backend: XXX-users-1
nsslapd-backend: XXX-users-2
nsslapd-backend: XXX-users-3
nsslapd-backend: XXX-users-4
nsslapd-backend: XXX-users-5
nsslapd-backend: XXX-users-6
nsslapd-backend: XXX-users-7
nsslapd-backend: XXX-users-8
nsslapd-backend: XXX-users-9
nsslapd-backend: XXX-users-10
nsslapd-backend: XXX-users-11
nsslapd-backend: XXX-users-12
nsslapd-backend: XXX-users-13
nsslapd-backend: XXX-users-14
nsslapd-backend: XXX-users-15
nsslapd-backend: XXX-users-16
nsslapd-backend: XXX-users-17
nsslapd-backend: XXX-users-18
nsslapd-backend: XXX-users-19
nsslapd-distribution-plugin: /usr/lib64/dirsrv/plugins/libdistrib-plugin.so
nsslapd-distribution-funct: hash_distribution

how can I check the 20 DBs?

Ah! You are using entry distribution. That explains it. The problem is that the hash_distribution function does not normalize the value first. Neither does the alpha_distribution function.

After retrieving the type and value from the RDN, the functions should normalize the value based on the syntax and matching rule of the type, and do the hash or alpha distribution based that normalized value. The alpha might not need it as it already does case insensitive comparisons, but it should be changed to be consistent.

Replying to [comment:4 rmeggins]:

Ah! You are using entry distribution. That explains it. The problem is that the hash_distribution function does not normalize the value first. Neither does the alpha_distribution function.

After retrieving the type and value from the RDN, the functions should normalize the value based on the syntax and matching rule of the type, and do the hash or alpha distribution based that normalized value. The alpha might not need it as it already does case insensitive comparisons, but it should be changed to be consistent.

Thanks Rich, so, it is a bug in the entry distribution plug-in?

Replying to [comment:5 nhosoi]:

Replying to [comment:4 rmeggins]:

Ah! You are using entry distribution. That explains it. The problem is that the hash_distribution function does not normalize the value first. Neither does the alpha_distribution function.

After retrieving the type and value from the RDN, the functions should normalize the value based on the syntax and matching rule of the type, and do the hash or alpha distribution based that normalized value. The alpha might not need it as it already does case insensitive comparisons, but it should be changed to be consistent.

Thanks Rich, so, it is a bug in the entry distribution plug-in?

Yes.

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1274420

Per triage, push the target milestone to 1.3.6.

Per triage meeting, set to FUTURE.

Finally, we have create a patch to solve this issue, patch included in comment.

We hope we can have it available soon in CentOS 7 rpm

@nhosoi @mreynolds I don't know entry distribution very well, but this patch seems sound to me. Do you mind having a look also.

Do you think it's worth writing a lib389 test for this case also?

Looks good to me, I don't think we need CI testing yet.

commit 29486e0
To ssh://git@pagure.io/389-ds-base.git
cf4ed63..29486e0 master -> master

Thanks for this @jmoral : I'm sorry it took so long to resolve.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1641

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.