I have an openldap server where I have people entered in basic inetOrgPerson format.
I am having an issue where it can't authenticate some users. I have narrowed things down to an issue where if I run:
ldapsearch -x -L -D "<myRootDn>" -W -b "<myBaseOU>" "uid=tony"
It successfully returns my user object. BUT if I run:
ldapsearch -x -L -D "<myRootDn>" -W -b "<myBaseOU>" -h localhost "uid=tony"
it will not find the object.
I seem to remember that ldapsearch with the default connect will open the DB files directly and read them ??? If so, why can ldapsearch find the object, but slapd can't. If not, what is happening that allows the previous option set to succeed while the second option set fails?
BTW: before I get asked, only some user objects are not found. i.e. "uid=kent" is found fine both ways. I tried to generalize my user object such that it isn't the content of the object that would cause the problem, but I also recognize that it is still a possible culprit.
This is running on a CentOS box. The RPM is openldap-servers-2.3.27-8.el5_1.3
Thanks in advance for any insight...
--On Wednesday, April 13, 2011 2:48 PM -0400 Michael Slack antonius.slack@gmail.com wrote:
I seem to remember that ldapsearch with the default connect will open the DB files directly and read them ??? If so, why can ldapsearch find the object, but slapd can't. If not, what is happening that allows the previous option set to succeed while the second option set fails?
ldapsearch does no such thing. All it ever does is contact an LDAP server over the specified URI. Now since your command works when you don't specify a URI, I advise you to look at the ldap.conf settings to see what ldapsearch fills in when you don't supply all the options.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org