GNOME Bugzilla – Bug 361413
LDAP search not functioning never prompts for password
Last modified: 2008-09-08 08:10:10 UTC
Please describe the problem: I have an openLDAP server running on one of my servers, the server works perfectly fine using a DN authentication through thunderbird. However when in evolution the exact same configuration doesn't function at all. If I attempt to search the status bar either reads searching... and never returns results, or nothing at all happens. My open ldap server is configured to authenticate through DNs only however I could attempt to set up sasl although this will break the users currently using the server via thunderbird. The curious thing is that I'm never prompted for a password, which obviously means that I will never be able to receive any data, as the server is configured to prevent anonymous access. This also explains when I click on find possible search bases I get an authentication error. It seems that to get this functionality working again a password must be prompted for in order to take care of the authentication side. After that it may function perfectly. Steps to reproduce: 1. Configure an openLDAP server 2. Configure evolution to connect to the LDAP server through DN auth 3. Attempt a search Actual results: No results returned or status bar reading searching indefinitely Expected results: Results to be returned promptly Does this happen every time? Yes Other information:
Hi Karl I couldn't reproduce this, with a newer version of evolution though, is this still an issue for you?. Thanks.
I'll test this when I'm back at work and have access to the openldap server
I've been testing this and I'm getting no result, here's the ldap server debug info; Successful connection via ldapsearch on the command line; --- connection_get(11) ==> bdb_bind: dn: cn=Manager,dc=kent-music,dc=com send_ldap_result: err=0 matched="" text="" connection_get(11) SRCH "dc=kent-music,dc=com" 2 0 0 0 0 filter: (|(cn=gates*)(sn=gates*)) attrs: bdb_idl_fetch_key: [b49d1940] bdb_idl_fetch_key: [75c0fb99] bdb_idl_fetch_key: [85af01d3] send_ldap_result: err=0 matched="" text="" connection_get(11) --- Evolution performing the same search; --- ==> bdb_bind: dn: cn=Manager,dc=kent-music,dc=com send_ldap_result: err=0 matched="" text="" connection_get(10) SRCH "dc=kent-music,dc=com" 1 0 100 0 0 filter: (|(cn=gates*)(sn=gates*)) attrs: bdb_idl_fetch_key: %dc=kent-music,dc=com bdb_idl_fetch_key: [b49d1940] bdb_idl_fetch_key: [75c0fb99] bdb_idl_fetch_key: [85af01d3] send_ldap_result: err=0 matched="" text="" connection_get(10) do_abandon: id=7 --- Evolution returns no results, but ldapsearch does. At least now I'm prompted for a password and it seems to authenticate properly, however I am asked for my password every time regardless of whether or not I click the remember password box. So evo+ldap is still broken for me, but the password is prompted at least, but is never remembered.
Passwords are made to be forgotten when the operations fails on the previous versions. We recently made it forget only if it is authentication fails. But I don't have a ldap server setup with me. I will try and get one asap and let you know after that.
I no longer have an LDAP server to test this, although I may set one up in the future. Please do not ask me to test in the mean time. Although a general call for testers may result in me replying.
I can reproduce this: slapd.conf (openldap) without "require authc": evolution auth via dn and no encryption, password is prompted and search results OK. slapd.conf with "require authc": evolution will not prompt for password when auth-dn and no encryption is set. Addressbooks of Thunderbird (Linux and Windows), OutlookExpress and TheBat! works perfectly in both configurations. The logfile shows, that evolution dont send any dn (sorry in advance if I am wrong). slapd log: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 busy >>> slap_listener(ldap:///) daemon: listen=9, new connection on 21 daemon: added 21r (active) listener=(nil) conn=8 fd=21 ACCEPT from IP=xxx.xxx.xxx.xxx:3832 (IP=0.0.0.0:389) daemon: activity on 2 descriptors daemon: activity on: 21r Aug 15 13:41:20 $SERVER slapd[12878]: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 21r Aug 15 13:41:20 $SERVER slapd[12878]: daemon: read active on 21 daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(21) connection_get(21): got connid=8 connection_read(21): checking for input on id=8 conn=8 op=0 do_bind >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=8 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=8 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=70218 tag=97 err=0 conn=8 op=0 RESULT tag=97 err=0 text= do_bind: v3 anonymous bind daemon: activity on 1 descriptor daemon: activity on: Aug 15 13:41:20 $SERVER slapd[12878]: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 21r Aug 15 13:41:20 $SERVER slapd[12878]: daemon: read active on 21 daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero connection_get(21) connection_get(21): got connid=8 connection_read(21): checking for input on id=8 conn=8 op=1 do_search >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 30 0 begin get_filter PRESENT end get_filter 0 filter: (objectClass=*) attrs: supportedControl supportedExtension supportedFeatures supportedSASLMechanisms supportedLDAPVersion subschemaSubentry schemaNamingContext Aug 15 13:41:20 $SERVER slapd[12878]: conn=8 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=8 op=1 SRCH attr=supportedControl supportedExtension supportedFeatures supportedSASLMechanisms supportedLDAPVersion subschemaSubentry schemaNamingContext send_ldap_result: conn=8 op=1 p=3 send_ldap_result: err=53 matched="" text="authentication required" send_ldap_response: msgid=70219 tag=101 err=53 conn=8 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=authentication required daemon: activity on 1 descriptor daemon: activity on: Aug 15 13:41:20 $SERVER slapd[12878]: daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=9 active_threads=0 tvp=zero
Created attachment 116690 [details] test patch eds
Created attachment 116691 [details] test patch evo just to safe time to someone willing to look on this during weekend. With these patches it asks for the password, but something is still wrong, because I got on evo's console: libebook-WARNING **: "e_book_authenticate_user" on book before "e_book_open" which is definitely wrong.
Created attachment 116867 [details] [review] proposed eds patch for evolution-data-server; The core of the fix, a little bit cheating and so on. It also doesn't try to bind anonymously if knows about required authentication, which was request for other bug I saw some time back but forgot the number already.
Created attachment 116870 [details] [review] proposed evo patch for evolution; Just a cosmetic patch, to print detailed errors for LDAP backends too. I do not know why I didn't do that in bug #547308 before. One thing I noticed, it shows the error with the detail "Authentication required" and then when I edit source and setup proper authentication method and login it doesn't connect. But the next start of the evolution it connects almost immediately. I guess some issue on ESource update after the change, because it tries to bind anonymously, with auth=none, which is nonsense, because I changed the auth to 'dn' and I was told for a password too. Anyway, that's the other bug for sure.
I dont think any string break. So commit
Patch in e-d-s committed to SVN trunk as r9492 http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=9492 Patch in evolution committed to SVN trunk as r36275 http://svn.gnome.org/viewvc/evolution?view=revision&revision=36275