[Freeipa-users] confused by ldapsearch results

Rob Crittenden rcritten at redhat.com
Tue May 19 20:25:56 UTC 2015


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: admin at EXAMPLE.COM
SASL SSF: 56
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.

rob




More information about the Freeipa-users mailing list