Summary: passwords with openldap 2.0 don't seem to work with openldap 2.2

Background:
I am migrating cyrus mail 9,000 users onto bigger hardware, two machines, etc.
User authentication is sasl with the info held in an openldap database.
After looong digging I find that the reason that users cannot login to imap
is down to the password in ldap somehow being wrong.

Old machine: openldap2-2.0.23   SUSE: Sles8
New machine: openldap2-2.2.6    SUSE: Sles9

The user information has been carried across in an ldif file.

The schema can't quite carry over since openldap 2.2 is more exacting than 2.0, 
so a few
fields I have to remove as I copied (users had 'objectClass: organization' & 
the such,
which the should not have).

I notice that /etc/openldap/schema/core.schema now (2.2) has commented out:
        attributetype ( 2.5.4.35 NAME 'userPassword'
but if I comment it back in openldap complains of duplicate attributeType.
I think that that is a red herring.

Passwords are set via a php script, the relevant bit is:
        $salt =  pack("C2",(rand(0, 26)+65),(rand(0, 26)+65));
        $md5pw = md5($password . $salt);
        $bin = pack('H*', $md5pw);
        $encpw = base64_encode($bin . $salt);
        $mods['userPassword'] = '{smd5}' . $encpw;      // $mods is the list of 
modifications
This works with openldap 2.0

The passwords that come out of ldapsearch look like:
        userPassword:: e3NtZDV9eUgrTHd1UUJENXl3RTlRaUpQNXZYbFpE
(for password 'password')

If I try and authenticate with that user (this works on the old machine):
        ldapsearch -LLL -b dc=example,dc=uk -D uid=testuser,dc=example,dc=uk -x 
-w password
it fails on the new system with:
        ldap_bind: Invalid credentials (49)

If (on the new system) I set the password on my testuser to (using slapadd):
        userPassword:: cGFzc3dvcmQ=
(also for 'password') authentication works properly.
I can't remember how I generated the above string, it is set for the cyrus user.

/etc/ldap.conf is the same on both machines.

/etc/slapd.conf contains (on both machines)
        password-hash   {smd5}


I set 'loglevel -1' and I get in syslog messages (date, etc removed):

        >>> dnPrettyNormal: <uid=testuser,dc=example,dc=uk>
        <<< dnPrettyNormal: <uid=testuser,dc=example,dc=uk>, 
<uid=testuser,dc=example,dc=uk>
        do_bind: version=3 dn="uid=testuser,dc=example,dc=uk" method=128
        conn=7 op=0 BIND dn="uid=testuser,dc=example,dc=uk" method=128
        ==> ldbm_back_bind: dn: uid=testuser,dc=example,dc=uk
        dn2entry_r: dn: "uid=testuser,dc=example,dc=uk"
        => dn2id( "uid=testuser,dc=example,dc=uk" )
        ====> cache_find_entry_ndn2id("uid=testuser,dc=example,dc=uk"): 19 (1 
tries)
        <= dn2id 19 (in cache)
        => id2entry_r( 19 )
        ====> cache_find_entry_id( 19 ) "uid=testuser,dc=example,dc=uk" (found) 
(1 tries)
        <= id2entry_r( 19 ) 0x817a160 (cache)
        => access_allowed: auth access to "uid=testuser,dc=example,dc=uk" 
"userPassword" requested
        => acl_get: [1] check attr userPassword
        <= acl_get: [1] acl uid=testuser,dc=example,dc=uk attr: userPassword
        => acl_mask: access to entry "uid=testuser,dc=example,dc=uk", attr 
"userPassword" requested
        => acl_mask: to all values by "", (=n)
        <= check a_dn_pat: anonymous
        <= acl_mask: [1] applying auth(=x) (stop)
        <= acl_mask: [1] mask: auth(=x)
        => access_allowed: auth access granted by auth(=x)
***
        send_ldap_result: conn=7 op=0 p=3
        send_ldap_result: err=49 matched="" text=""
        send_ldap_response: msgid=1 tag=97 err=49
        conn=7 op=0 RESULT tag=97 err=49 text=
        ====> cache_return_entry_r( 19 ): returned (0)
        daemon: select: listen=6 active_threads=0 tvp=NULL
        daemon: select: listen=7 active_threads=0 tvp=NULL
        daemon: activity on 1 descriptors
        daemon: activity on:
        9r

>From what I understand from the above (near '***') it decides that testuser is 
>allowed to try to auth,
but 2 lines later goes 49 (== invalid credentials), unfortunately it gives me 
no clue as to what it is about
the credentials that is wrong. I find that puzzling since the credentals work 
on the old system.

I am at a loss .... has anyone got pointers please.

TIA

-- 
Alain Williams
Parliament Hill Computers Ltd.
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/

#include <std_disclaimer.h>

Reply via email to