Yes, Those are the rootdn for company LDAP. And if I run ldapsearch -h olddir -x -D "cn=company,dc=company dc=edu" -w "Password" uid=foo
or ldapsearch -h newdir -x -D "cn=company,dc=company dc=edu" -w "Password" uid=foo
I get same error message in output file
-----Original Message----- From: Prentice Bisbal [mailto:prentice@ias.edu] Sent: Tuesday, October 26, 2010 2:52 PM To: Darouichi, Aziz; openldap-technical@openldap.org Subject: Re: ldapsearch problem
Is the DN "cn=company,dc=company dc=edu" the root DN for your LDAP server, if not, it shouldn't be able to read the userPassword attribute. That attribute is usually not readable by anyone other than the rootdn for security reasons. Anyone can auth, but "auth" is not the same as "read"
You either need to search for userPassword using the same dn specified as the rootdn in your slapd.conf file, or explicitly give "cn=company,dc=company dc=edu" read access to userPassword.
Prentice
Darouichi, Aziz wrote:
Hi All,
I inherited openldap-2.2.13-12.el4. that was built by a vendor few years ago, This is running in a production. I built a new
openldap-2.3.43-12.el5_5.2. I run a backup of production LDIF file. Imported to the new openldap-2.3.43-12.el5_5.2. deleted all files from /var/lib/ldap except alock and DB_CONFIG file after I stopped services. I run slapadd –v –c –l backup_filename.ldif –f /etc/openldap/slapd.conf
import.log
After the import is done I changed owner to be ldap. I started services. Now when I run a search for users passwords
ldapsearch -x -D "cn=company,dc=company dc=edu" -w “Password” userPassword > file.txt
This is the output in file.txt :
# extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (objectclass=*) # requesting: userPassword #
# search result search: 2 result: 32 No such object
# numResponses: 1
If I run same in production server I get user’s passwords.
Thanks