On Tue, 2003-02-11 at 14:52, Tony Earnshaw wrote: > tir, 2003-02-11 kl. 20:02 skrev David R. Van Sandt: > > > I have been complaining about this same issue for the past couple > > months (ever since using Evo). I enter the SAME exact DN and Seach > > base as I use in outlook. And then click on Show supported bases > > or just try to use it.. and it NEVER prompts for my password. I usually > > have to kill the app as it never comes back. > > > > I just upgraded to evo 1.2.2 in hopes that it might work. Still no workie. > > > > For what it's worth, I am also using port 636 and it says Always (greyed) > > on use SSL - which is what I need. Here's some wombat output... > > <big snip> > > > I had to runkillev as evo was nonresponsive. That happens whenever I try to > > access the ldap server. > > > > Perhaps someone could actually try to assist us in figuring out what is > > wrong here. I'd like to continue to use EVO, but, I need access to my > > company LDAP.
Hmm, I didn't receive this mail that Tony's responding to... private mail? Anyway, I investigated this a little the last time you (David) sent mail about it back in December I think? There wasn't much that could be determined from my end here.. "openssl s_client" prints out the cert fine, but ldapsearch hangs, just like evolution does. The error the wombat printed out was 0x55 (LDAP_TIMEOUT), which is the same behavior as the command line tool. This might be some failing with openssl, I don't know. What server is this? openldap? Do you have any openssl based tools that work with your server? > O.k. I run my own ldap server, so I can configure it how I like :-) > > If your firm only has its LDAP server available on port 636/SSL (or even > on 389/TLS) then Evo LDAP probably won't work for you. Or at the very > best, only sporadically. However, this is nothing to do with > authenticating with any DN, which is the normal procedure > > My experience is, that there always have been and still are, a few > things wrong with the Evo SSL/TLS implementation. The worst of these is, > that it doesn't work. Why it doesn't work I don't know (and at the > moment I couldn't care less as long as it works vanilla on port 389). I > can debug from the server side (Openldap 2.1.12 server at debug d-1), > but that's Ximian's job, not mine. OTOH, the smtp mail TLS > implementation works perfectly. > > Work on Evo ldap is only done sporadically, since up to now few people > have used it or complained when it doesn't work - at least that's the > info I've gleaned from this list. > > An LDAP client *should* be able to bind with SSL or TLS and strong SASL > authentication. If the Evo smtp client can do all of this, including a > subset of SASL, then there's no reason that the LDAP client shouldn't. > But only if people work on it. While I agree that evolution should do both SSL/TLS (which it does for me here, without problem) and SASL (which is planned), there isn't a connection between what's possible in the mailer and the addressbook unfortunately. They're completely separate codebases, and they even use a different SSL library (a fact that annoys me greatly). The mailer also has access to the SSL library at a much lower level than the openldap api provides us. We just call ldap_start_tls and hope for the best. Chris _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
