[Date Prev][Date Next]
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.
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
> 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.