[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