You might want to look back at my posts on the recent SQL auth problems, sound very similar.

Regards Andrew

On Tue, 2005-04-12 at 18:25 +0200, Thomas Hummel wrote:

Hello,

I've been trying to figure out what's wrong with authentication against an ldap pass/user db with test67 as test62 was working fine.

[ The problem is the same as previously described in this list :

• FreeBSD-5.3
• dovecot-1.0-test67
• openldap-2.1.27

--> "ldap(dovetest,127.0.0.1): No password in reply" --> "NO Temporary authentication failure."

or

-- dovecot: Apr 12 18:22:41 Info: auth(default): client in: AUTH 1 PLAIN service=IMAP lip=157.99.64.42 rip=157.99.64.42 dovecot: Apr 12 18:22:41 Info: auth(default): client out: CONT 1 dovecot: Apr 12 18:22:41 Info: auth(default): client in: CONT 1 AGRvdmV0ZXN0AGZvbw== dovecot: Apr 12 18:22:41 Info: auth(default): ldap(dovetest,157.99.64.42): base=ou=personnes, dc=pasteur, dc=fr scope=subtree filter=(&(objectClass=posixAccount)(uid=dovetest)) fields=uid,homeDirectory,,,uidNumber,gidNumber dovecot: Apr 12 18:22:42 Info: auth(default): client in: AUTH 2 PLAIN service=IMAP lip=157.99.64.42 rip=157.99.64.42 resp=AGRvdmV0ZXN0AGZvbw== dovecot: Apr 12 18:22:42 Info: auth(default): ldap(dovetest,157.99.64.42): base=ou=personnes, dc=pasteur, dc=fr scope=subtree filter=(&(objectClass=posixAccount)(uid=dovetest)) fields=uid,homeDirectory,,,uidNumber,gidNumber

dovecot: Apr 12 18:22:42 Error: auth(default): ldap(dovetest,157.99.64.42): No password in reply dovecot: Apr 12 18:22:42 Error: auth(default): file passdb-ldap.c: line 122 (handle_request): assertion failed: (scheme != NULL) dovecot: Apr 12 18:22:42 Error: child 43147 (auth) killed with signal 6

]

I've noticed the following changes in the source code, and my understanding (which may be wrong) of my problem goes as follows :

• In test62, the 'attr_names' attribute array was defined outside the 'ldap_connection' struct, thus allowing 'passdb_ldap_conn' and 'userdb_ldap_conn' structs to have different array of such type.

• At the opposite, in test67, the 'attr_names' array is inside the 'ldap_connection'. As 'passdb_ldap_conn' and 'userdb_ldap_conn' are of the 'ldap_connection' type and since the 'db_ldap_init' function returns the existing ldap connection if it exists, the 'passdb_ldap_preinit' and 'usedb_ldap_preinit' will call the 'db_ldap_set_attrs' function on _the same_ 'ldap_connection' object.

• So when the 'db_ldap_search' function is called from the 'passdb-ldap.c:ldap_lookup_pass function, the 5th argument (passdb_ldap_conn->attr_names) will point to the 'user_attrs' instead of the 'pass_attrs', since userdb_preinit will have already been called.

• I've also noticed the use of the 'attr_map' hash to store the attribute/value pairs, but since it doesn't seems to be used when calling 'ldap_lookup_pass', I guess the problem is somewhere else.

Can someone give me a clue ? Has someone successfully set up dovecot-1.0-test67 on a similar configuration ?

thanks

-- Andrew Hutchings (A-Wing) Linux Guru - Netserve Consultants Ltd. - www.domaincity.co.uk Random BOFH excuse: T-1's congested due to porn traffic to the news server.