Boyce, George Robert. (GSFC-762.0)[NICS] wrote:
I don’t understand what is happening…

If I use a compound OR filter to search for “cn” or “uid”, I only get
back the match for uid. I expect to get both. If I add a search for a
nonexistent attribute like “name”, I get nothing back. I expect to get
back the entry matched by the other term.

# l "(cn=gboyce)" dn

dn: cn=gboyce,cn=groups,cn=accounts,dc=…

# l "(uid=gboyce)" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(uid=gboyce)(cn=gboyce))" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(cn=gboyce)(uid=gboyce))" dn

dn: uid=gboyce,cn=users,cn=accounts,dc=…

# l "(|(uid=gboyce)(name=gboyce))" dn


This is on a new deployment of ipa on centos, with just a couple of test
records. I don’t have much recent experience with LDAP, but I don’t see
what I’m doing wrong. Dirsrv on centos 6.5 works as expected.

You don't get a separate entry back for each part of the filter that matches. If it matches on any one of the OR elements you get it back, otherwise you don't. In other words, for this type of search you're likely to get either one or zero entries back.

I don't see why adding a non-existent attribute in the filter would cause it to do anything odd. That part of the filter should be a no-op.

This worked for me:

$ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm "(|(uid=admin)(name=admin))" dn
SASL/GSSAPI authentication started
SASL username:
SASL data security layer installed.
dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com

Note that cn is Common Name which is set to the user's full name, in this case likely "George Boyce". So that will never match gboyce.


Manage your subscription for the Freeipa-users mailing list:
Go to for more info on the project

Reply via email to