Hello,
I'm wondering if the following situation is valid (though I think it
isn't since I still cannot authenticate with ldap pass/userdb on
test67 running on FreeBSD-5.3).
Is it normal that the passdb_ldap_conn->attr_names second element (for
instance) "turns to" "homeDirectory" as the following step
by step gdb
run sample shows ? :
--
Breakpoint 1, userdb_ldap_preinit (args=0x80796d0
"/usr/local/dovecot/etc/dovecot-ldap.conf")
    at userdb-ldap.c:201
201             userdb_ldap_conn = db_ldap_init(args);
(gdb) p passdb_ldap_conn->attr_names[1]
$1 = 0x8079990 "userPassword"
(gdb) cont
Continuing.
Breakpoint 2, userdb_ldap_init (args=0x80796d0
"/usr/local/dovecot/etc/dovecot-ldap.conf")
    at userdb-ldap.c:208
208             (void)db_ldap_connect(userdb_ldap_conn);
(gdb) p passdb_ldap_conn->attr_names[1]
$2 = 0x80799e0 "homeDirectory"
(gdb) cont
Continuing.
Breakpoint 3, ldap_lookup_pass (auth_request=0x5, ldap_request=0x14) at
passdb-ldap.c:157
157             struct ldap_connection *conn = passdb_ldap_conn;
(gdb) p passdb_ldap_conn->attr_names[1]
$3 = 0x80799e0 "homeDirectory"
(gdb) cont
Continuing.
--
Could it explain why I get 
- in the error log :
--
dovecot: Apr 08 18:08:15 Error: auth(default): ldap(dovetest,127.0.0.1): No
password in reply
dovecot: Apr 08 18:08:15 Error: auth(default): file passdb-ldap.c: line 122
(handle_request): assertion failed: (scheme != NULL)
--
- in the info log :
dovecot: Apr 08 18:08:15 Info: auth(default): ldap(dovetest,127.0.0.1):
base=ou=personnes, dc=pasteur, dc=fr scope=subtree
filter=(&(objectClass=posixAccount)(uid=dovetest))
fields=uid,homeDirectory,,,uidNumber,gidNumber
?
Thanks for your help.
-- 
Thomas Hummel 	    | Institut Pasteur
<hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau
On Fri, 2005-04-08 at 18:11 +0200, Thomas Hummel wrote:> I'm wondering if the following situation is valid (though I think it > isn't since I still cannot authenticate with ldap pass/userdb on > test67 running on FreeBSD-5.3). > > Is it normal that the passdb_ldap_conn->attr_names second element (for > instance) "turns to" "homeDirectory" as the following step by step gdb > run sample shows ? :Ah, right. Does the attached patch fix it? -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap.diff Type: text/x-patch Size: 6090 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20050417/6f0e799b/attachment-0002.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20050417/6f0e799b/attachment-0003.bin>
On Sun, Apr 17, 2005 at 07:51:24PM +0300, Timo Sirainen wrote:> On Fri, 2005-04-08 at 18:11 +0200, Thomas Hummel wrote: > > > > Is it normal that the passdb_ldap_conn->attr_names second element (for > > instance) "turns to" "homeDirectory" as the following step by step gdb > > run sample shows ? : > > Ah, right. Does the attached patch fix it?Well, thank you Timo, your patch actually fixed the wrong attr_names value. However, I'm having another problem that I hadn't in test62 : I've got a password mismatch altough the password is correct (works on an ldapsearch command line request), and password's scheme (CRYPT) too (same scheme in LDAP and in dovecot-ldap.conf). I'm going to trace that to see where it comes from. -- dovecot: Apr 18 11:42:27 Info: auth(default): ldap(dovetest,157.99.64.42): password mismatch -- -- Thomas Hummel | Institut Pasteur <hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau