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
--On Tuesday, October 26, 2010 01:58:06 PM -0400 "Darouichi, Aziz" adarouic@post03.curry.edu 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
Why don't you start by comparing an individual entry in each directory? Something like:
% ldapsearch -h olddir -x -D "cn=company,dc=company dc=edu" -w "Password" uid=foo
% ldapsearch -h newdir -x -D "cn=company,dc=company dc=edu" -w "Password" uid=foo
Bill
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
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
Add this access control to your slapd.conf:
access to attrs=userPassword by dn="cn=company,dc=company dc=edu" read
That should allow to read the userPassword
-- Prentice
Darouichi, Aziz wrote:
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
openldap-technical@openldap.org
-
Bill MacAllister -
Darouichi, Aziz -
Prentice Bisbal