Hello Timo, your patch introducing pass_attr_names and user_attr_names fixed the problem of the 'shared' attr_names member of [passdb|userdb]_ldap_conn as I answered in the relative thread. Now I think there is a problem while comparing user-provided and ldap-provided passwords causing a false 'password mismatch' situation, while using PLAIN mechanism with LDAP authentication. As a matter of fact, the user provided by the user, as read in the 'mech_plain_auth_continue' function is passed as an argument in the 'auth_request_verify_plain' function which, in turns pass it to the function pointed to by 'passdb->verify_plain' (that is 'ldap_verify_plain') which doesn't use it [instead maybe of setting the 'passdb_ldap_request' 'password' field with it ?]. So once back from the LDAP request, when in 'handle_request' we call 'password_verify', the password we try to match against the one read in the LDAP db is null. Did I get it right ? Thanks -- Thomas Hummel | Institut Pasteur <hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau
On Mon, Apr 18, 2005 at 06:51:17PM +0200, Thomas Hummel wrote:> 'auth_request_verify_plain' function which, in turns pass it to the > function pointed to by 'passdb->verify_plain' (that is > 'ldap_verify_plain') which doesn't use it [instead maybe of setting > the 'passdb_ldap_request' 'password' field with it ?].A quick and dirty fix confirms what I was saying : If I add : strncpy(ldap_request->password,password,50); in auth/passdb-ldap.c:ldap_verify_plain the authentication against LDAP works correctly. I don't send a real patch since, of course, the correct way to do the same fix is to use your pool and string dupliation functions, which I'm not quite used to yet. I'm either waiting for your confirmation and/or official patch, or I'm going to read more about those functions. thank you -- Thomas Hummel | Institut Pasteur <hummel at pasteur.fr> | P?le informatique - syst?mes et r?seau