Re: question about binding to our new openldap server

[Emily Backes <ebackes@symas.com>]

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).

-- 
Emily Backes
Symas Corporation
ebackes@symas.com