GNOME Bugzilla – Bug 502203
Exchange operations broken
Last modified: 2008-02-05 18:37:39 UTC
Please describe the problem: I've upgraded to evolution/gnome 2.21.3 using garnome svn/trunk. Something has broken with my exchange accounts. I've built my own openldap (version 2.4.6) to which the openldap-NTLM patch was applied. My exchange account is of the form username.department@host and my OWA URL is of the form http://server/exchange/username.department@host. I've tried both plaintext and secure authentication. The gal server is a different machine. OK here's what happens: With either kind of authentication, e-mail works. I see my exchange folder tree and the standard operations seem to work. With plaintext authentication the exchange calendar works; however, with secure authentication I get a popup stating: Error on exchange:// username.department@host;auth-Basic@exchange.mcgill.ca/: Could not find the calendar. The gal never works. Again, note that the GAL server here is different than the one storing the other exchange data. All of this used to work a few revisions ago, although I've wemt back to 2.21.1 and things are still broken. A couple of other things: 1. I've used gconf-editor to look for the name of the GAL server. It doesn't seem to exist, even though it's correctly shown in the account setup GUI. The entry in apps/evolution/addressbook/sources is wrong. (It points to the exchange server and has auth=BASIC for a start). 2. I've run a packet sniffer while evo was starting up. I see no traffic going to the GAL server, just to the exchange (e-mail & calendar) server. 3. My ~/.gnome2_private/Evolution (after trying both types of authentication) has the following: [Passwords-Exchange] exchange:__user.department%40host;auth_NTLM@exchange.mcgill.ca_=encrypted= exchange:__user.department@host;auth_Basic@exchange.mcgill.ca_=encrypted= exchange:__user.department%40host;auth_Basic@exchange.mcgill.ca_=encrypted= [Passwords-Mail] pop:__user@host_=encrypted== It looks like the failed connection types never get stored. 4. I've played around with some of evo and friends' svn/trunk sources (to see if another bug I'm worried about is fixed) and was concerned that perhaps some of my configuration files had gotten messed up. I get the same problem starting from a completely new test account. 5. I've run evolution and e-d-s in console windows and captured the output. I will attach this as soon as I submit the report. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 100473 [details] Screen capture of evolution session with E2K_DEBUG=5 This file contains two evolution sessions. In the first, I had plaintext authentication, while in the second, secure. In either case I went from the mail to calendar to gal, supplying the correct password if prompted.
Created attachment 100474 [details] Screen Capture of e-d-s with E2K_DEBUG=5 Here's what e-d-s was doing.
Varadhan, can you look at this, please? I have no other idea than I gave to David. Thanks.
David: Was it working with any prior version of Evolution? If so, can you give us the version number that it worked with? Also, did you try changing the GAL server details in the preferences? did it reflect in the gconf?
Thanks for the reply. 1. It has worked reliably in the near past. One of my attempts was to revert to an earlier version (I tried the 2.21.1 and .2) the problem has not gone away, which leads me to suspect that it may lie in one of the other libraries evo and friends use. I've played around with openldap, trying versions 2.3.39 and 2.4.6, applying the openldap-ntlm.diff patch in both cases. This had no effect. I've applied several system-level patches (I run slackware-12.0) in the last little while, but don't recall evo breaking after any of them. 2. I have tried changing the gal server name in preferences. As far as I can tell, it doesn't appear in gconf. This could be because evo "tests" the server and if it fails refuses to update gconf.
Another observation. I finally got a packetsniffer configured properly and was able to monitor some of the transactions. 1. There were checksum errors in some of the authentication transactions with the GAL. 2. The GAL returned an error message complaining about authentication (no surprise). This is consistent with my observation that reverting evo and friends versions to earlier versions didn't help. So given that I build my own version of ldap: a) Should I apply the openldap-ntlm patch? b) What configure flags should I use? I've tried several, and am currently using: --disable-static --disable-debug --enable-ldap --enable-crypt --with-tls --with-threads --enable-backends --disable-sql Comments?
Here's an update after I've upgraded to 2.21.4. I no longer get authentication failed on the GAL. However, once I authenticate, and try a search, nothing is returned. Worse, checking the preferences shows that evo has reverted the authentication method to plaintext, even though I have set it to secure. In addition, it seems to forget the GAL server address. My suspicion is that our exchange folks have allowed plaintext access to the mail and calendar server but enforce secure for the GAL. From what I can tell, there seems to be a problem with NTLS lookup. Running a sniffer (wireshark) shows errors like; LDAPMessage bindResponse(2) invalidCredentials (8009030C: LdapErr: DSID-0C09053B, comment: AcceptSecurityContext error, data 0, vece) What's interesting is that the preceding packet always seems to have a tcp checksum error. E.g., LDAPMessage bindRequest(2) ntlmsspAuth which preceded the preceding error.
I upgraded to evolution 2.21.90. The problem seems to have been fixed. I'm closing this one.