[389-users] upgraded to latest 389, ldapsearch returns no results

[Brian High]

Hi 389-users,

Perhaps you can help solve a mystery for me.

I just upgraded 389 Directory on RHEL5, 64bit from 389-ds-base 1.2.2 to 1.2.9.9.

  yum --enablerepo=epel upgrade
  setup-ds-admin.pl -u

... as prescribed in the release notes:

  http://directory.fedoraproject.org/wiki/Release_Notes


Here is the problem.  I used to be able to query using ldapsearch like
this (anonymous bind):

  ldapsearch -x -ZZ -h <HOST> -b <BASE> -LLL "(uid=<USER>)" gecos

And I would see:

  dn: uid=<USER>,<BASE>
  gecos: System User


Now, after the upgrade, this returns no results and no errors, but if
I bind like this (authenticated bind), then it works _fine_:

  ldapsearch -x -ZZ -D "cn=directory manager" -W -h <HOST> -b <BASE>
-LLL "(uid=<USER>)" gecos


Here is some log output showing the anon. bind search and the
non-anon. bind search (sanitized):

[07/Dec/2011:14:52:14 -0800] conn=120 SSL 256-bit AES
[07/Dec/2011:14:52:14 -0800] conn=120 op=1 BIND dn="" method=128 version=3
[07/Dec/2011:14:52:14 -0800] conn=120 op=1 RESULT err=0 tag=97
nentries=0 etime=0 dn=""
[07/Dec/2011:14:52:14 -0800] conn=120 op=2 SRCH
base="dc=EXAMPLE,dc=COM" scope=2 filter="(uid=USERNAME)" attrs="gecos"
[07/Dec/2011:14:52:14 -0800] conn=120 op=2 RESULT err=0 tag=101
nentries=0 etime=0
[07/Dec/2011:14:52:14 -0800] conn=120 op=3 UNBIND
[07/Dec/2011:14:52:14 -0800] conn=120 op=3 fd=71 closed - U1

[07/Dec/2011:14:53:37 -0800] conn=121 SSL 256-bit AES
[07/Dec/2011:14:53:40 -0800] conn=121 op=2 BIND dn="cn=directory
manager" method=128 version=3
[07/Dec/2011:14:53:40 -0800] conn=121 op=2 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[07/Dec/2011:14:53:40 -0800] conn=121 op=3 SRCH
base="dc=EXAMPLE,dc=COM" scope=2 filter="(uid=USERNAME)" attrs="gecos"
[07/Dec/2011:14:53:40 -0800] conn=121 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[07/Dec/2011:14:53:40 -0800] conn=121 op=4 UNBIND
[07/Dec/2011:14:53:40 -0800] conn=121 op=4 fd=71 closed - U1

The only difference I can see is the nentries=1 in the latter test.

So, I looked into the latest features and see there are some more

  nsslapd-anonlimitsdn:
  nsslapd-allow-anonymous-access: on

... which I have left as defaults.  It looks like anonymous binds
should still work.

So, I am wondering, why do anonymous binds no longer return results?

--Brian