search for: passdb_ldap_conn

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

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

...uth/passdb-ldap.c) just before loging the ldap request parameters (auth_request_log_debug) and to actually perform the search (db_ldap_search). The signal occurs on the call of t_strarray_join(attr_names, ",") What I'm observing is that the "attr_names" array of the "passdb_ldap_conn" ldap connection doesn't seem to hold the right attributes : while in the test62 version it holded 'uid' and 'userPassword', it holds now 'uid' and 'homeDirectory'. As a matter of fact, the content of this array seem to change between the "preinit"...

The attached patch makes the local IP address to which the client connected available to the authentication modules; i.e., the local IP address is available for substitution as %i for the mysql and pgsql modules. We needed this feature to support thousands of our legacy accounts which are authenticated by username/local_part (not the full email address) and IP address (one per domain). Timo,