Hello, Holly.
We just upgrade our OS system and installed the most recent openldap version: 2.4.4.
Are you sure?
Version numbers in most modern software products should be considered as a dot-separated sequence of numbers, not a fractional number.
2.4.4 Date: Tue Feb 13 21:21:56 2007 +0000 (alpha release of 2.4) 2.4.40 Date: Thu Sep 18 20:48:49 2014 -0500
There have been some changes in those 7.5 years of development.
I moved the config file and related openldap data files from older version 2.3.4 onto this new server. I can't make successful binding at this moment. The following is from the log file.
I can't imagine why you would have ever run 2.3.4 either. Please check that you're reporting actual version numbers without random abbreviations.
Should I install the same version of openldap on this new box since I am trying to binding with old data file?
No, but 2.2 and 2.3 are quite antique and more or less like upgrading from an alien environment at this point.
Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=1 SRCH base="ou=Auth,o=csun" scope=0 deref=0 filter="(objectClass=*)" Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=1 SRCH attr=1.1 Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
Err=32 is No such entry, which means the BASE of your search-- ou=auth,o=csun does not exist or is hidden from your currently bound identity (anonymous). You can find error codes in the Administrator's Guide, which is on the OpenLDAP web site.
Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=2 SRCH base="ou=Auth,o=csun" scope=0 deref=0 filter="(objectClass=*)" Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text=
Here, the client is mindlessly repeating the same wrong query with some vague expectation that the result will be different-- only milliseconds later. Brilliant!
Mar 11 13:21:47 oldaptest01 slapd[28623]: conn=1039 op=3 SRCH attr=objectclass subschemaSubentry
You can find the subschemaSubentry location information in the Root DSE, as with any LDAPv3 compliant server. I recommend trying the Apache Directory Studio as a browser, it can help navigate what you have and better understand how things are positioned.
Mar 11 13:22:05 oldaptest01 slapd[28623]: conn=1040 fd=13 ACCEPT from IP=130.*.*.*:62211 (IP=0.0.0.0:389) Mar 11 13:22:05 oldaptest01 slapd[28623]: conn=1040 op=0 BIND dn="cn=directory manager,o=csun" method=128 Mar 11 13:22:05 oldaptest01 slapd[28623]: conn=1040 op=0 RESULT tag=97 err=49 text= Mar 11 13:22:07 oldaptest01 slapd[28623]: conn=1040 op=1 UNBIND
This is the first actual BIND attempt with a password. Most likely cn=directory manager,o=csun is not actually in the tree and is specified with a rootdn/rootpw pair in the configuration file (slapd.conf) that you forgot to copy over.
That said, if the passwords in the directory are {CRYPT} hashed, you'll want to ensure that is enabled in your configure line when building. (And start moving people to a more secure hash sooner rather than later).