Bug 205362 - [RHEL4] evolution-connector on x86_64 not able to authenticate using POP/IMAP over SSL and NTLM/SPA
Summary: [RHEL4] evolution-connector on x86_64 not able to authenticate using POP/IMAP...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution-connector
Version: 4.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Matthew Barnes
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-06 12:27 UTC by Monit Kapoor
Modified: 2008-03-10 06:02 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2008-03-10 06:02:09 UTC

Attachments (Terms of Use)
Requested debug log (17.56 KB, text/plain)
2008-01-10 07:42 UTC, Göran Uddeborg
no flags Details
Debug output from working session (18.63 KB, text/plain)
2008-01-10 07:53 UTC, Göran Uddeborg
no flags Details

Description Monit Kapoor 2006-09-06 12:27:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Description of problem:
I am seeing issues authenticating to our Exchange server's using IMAP over SSL and NTLM/SPA.

I upgraded the libsoup libraries as suggested by the errata "http://rhn.redhat.com/errata/RHBA-2006-0003.html"
and i see proper authentication only 1 out of 10 tries i attempt to provide my password(Earlier it just kept failing).

POP does not work at all with SSL and NTLM.

The above works if i just select "plain password" as authentication mechanism.

Following is the list of installed RPM's for evolution and libsoup.

evolution-connector            2.0.2      5          x86_64
evolution-devel                2.0.2      16         x86_64
evolution-data-server-devel    1.0.2      7          x86_64
libsoup                        2.2.1      4          x86_64
evolution-webcal               1.0.10     1          x86_64
evolution                      2.0.2      16         x86_64
libsoup-devel                  2.2.1      4          x86_64
libsoup                        2.2.1      4          i386
evolution-data-server          1.0.2      7          x86_64
evolution-data-server          1.0.2      7          i386

I have tested this on a RHEL4 update 4 system as well and found it to be failing.

Version-Release number of selected component (if applicable):
RHEL4 update1 with latest libsoup 2.2.1-4

How reproducible:

Steps to Reproduce:
1. Configure evolution to connect to exchange server POP/IMAP using SSL and NTLM/SPA.
2. Type passwd to authentiacte user.

Actual Results:
1. Authentication fails with error "bad username/password"
2. Trying to provide password a couple of times may eventually authenticate once.
3. That too it only succeeds for IMAP. POP is still broken.

Expected Results:
The first attempt to authenticate should work for both IMAP/POP

Additional info:

Comment 1 Matthew Barnes 2007-10-02 18:09:18 UTC
Is this bug still present in Fedora 8 Test 2 or later?

Comment 3 Matthew Barnes 2007-11-08 18:36:50 UTC
Oops, my mistake in comment #1.  I didn't notice that this is a RHEL bug.

RHEL 4.6 introduced an option to upgrade to Evolution 2.8 as shipped in RHEL5. 
The upgrade is self-contained in terms of dependencies; it won't force you to
upgrade your entire desktop environment.  You can try it by installing the
"evolution28" package.

The upgrade option also placed Evolution 2.0.2 in maintainance mode, meaning
it's only receiving security updates now.  If you're still interested in this
bug, can you please check whether the issue still exists in the "evolution28"

Comment 4 Göran Uddeborg 2008-01-09 15:29:20 UTC
We are trying to use evolution28 on our RHEL4 machines.  It fails to connect to
our Exchange server on x86_64 machines, while it works fine on i386 machines. 
Using the same account.  (The account works fine using the regular evolution 2.8
on a RHEL5 machine.)

Comment 5 Göran Uddeborg 2008-01-09 15:30:28 UTC
I meant to say: The account works fine using the regular evolution 2.8 on an
x86_64 RHEL5 machine.)

Comment 6 Matthew Barnes 2008-01-09 20:05:09 UTC
So you're saying authentication works on both i386 and x86_64 machines running
RHEL5 and i386 machines running RHEL4, but fails on x86_64 machines running RHEL4.

Can you try to capture some debugging output for me to look at?  Try running the
following from a terminal and then post the evo.log file if it manages to
capture communication between Evolution and Exchange:

   $ E2K_DEBUG=5 evolution >& evo.log

(See http://www.gnome.org/projects/evolution/bugs.shtml for more details.)

Comment 7 Göran Uddeborg 2008-01-10 07:42:40 UTC
Created attachment 291241 [details]
Requested debug log

I hadn't tried the RHEL5/i386 combination.  But I did now, and it works fine. 
So yes, the situation is as you assume.

Did you want me to do anything in particular when running evolution with debug
enabled?  The log is from starting evolution which comes up in calendar mode,
and then clicking the evolution calendar a few times.  The symptom in this case
is that meetings in the evolution calendar never show.	Meetings in my local
calendar show as expected.  (The checkbox comes on and off as expected,

Comment 8 Göran Uddeborg 2008-01-10 07:45:08 UTC
Is this bugzilla cursed?  I managed to mistype again!

When I said "evolution calendar" in comment 7 I meant "exchange calendar".

Comment 9 Göran Uddeborg 2008-01-10 07:53:34 UTC
Created attachment 291243 [details]
Debug output from working session

In case it might be of any help, I also enclose a log when running with
E2K_DEBUG on RHEL5/x86_64, where things work as expected.

Comment 10 Matthew Barnes 2008-01-10 15:12:52 UTC
Thanks for both logs, that's a good idea.  Unfortunately, for the purpose of
investigation, they both seem to show a successful authentication.  If I'm
reading this right, the interaction goes...

# Evolution requests authorization

GET /exchange/goran.uddeborg@jeppesen.com/ HTTP/1.1
E2k-Debug: 0xd1ea010 @ 1199951342
Host: gotmail1.jeppesensystems.com
Accept-Language: sv-SE, sv, en
Authorization: NTLM [...snipped...]
User-Agent: Evolution/1.8.0

# Exchange denies and posts a challenge

401 Unauthorized
Content-Length: 83
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM [...snipped...]
X-Powered-By: ASP.NET
Date: Thu, 10 Jan 2008 07:49:02 GMT

# Evolution replies

GET /exchange/goran.uddeborg@jeppesen.com/ HTTP/1.1
E2k-Debug: 0xd1ea010 @ 1199951342 [restarted]
Host: gotmail1.jeppesensystems.com
Accept-Language: sv-SE, sv, en
Authorization: NTLM [...snipped...]
User-Agent: Evolution/1.8.0

# Exchange grants access and provides a session ID

200 OK
Date: Thu, 10 Jan 2008 07:49:02 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Set-Cookie: sessionid=552e6b6d-6c5d-4863-b5cd-8b6c9a70eef5:0x41d;
Content-Type: text/html
Content-Length: 1149
MS-WebStorage: 6.5.7638
Cache-Control: no-cache

Both logs show the same sequence of events.

Can you check that you're following the steps to reproduce in comment #0 and try
accessing your email this time with E2K_DEBUG=5 active?

Comment 11 Matthew Barnes 2008-01-10 15:18:23 UTC
I did notice these warnings in the first log but not the second, which may help
explain the calendar failure.

(evolution:9647): calendar-gui-WARNING **: gnome-cal.c:855: Could not create the

(evolution:9647): calendar-gui-CRITICAL **: e_week_view_add_event: assertion
`end > add_event_data->week_view->day_starts[0]' failed

But this bug is about accessing Exchange mail via POP or IMAP.  We can deal with
the calendar warnings separately.

Comment 12 Göran Uddeborg 2008-01-10 17:10:06 UTC
I also thought it looked like successful authentication.  But I don't trust my
assumptions when it comes to Exchange servers ...

The warnings you noticed in the log are from the successful case!  In the log
for the failure case, there doesn't seem to be such warnings.

On reproducing more exactly comment 0, maybe my and Monit Kapoor's problem
aren't the same after all.

I had my Evolution configured to use "Microsoft Exchange" as the server type for
receiving mail.  That seems to fail on RHEL4/x86_64 only.  It seems to fail at
the same time as the calendar problem occurs.

I now tried to set things up more exactly as in comment 0, and I get a different
behaviour.  With IMAP, SSL, and NTLM/SPA i can never access my mail.  The
connection is always "unexpedly disconnected".  But that could be that there is
some setting on our Exchange server that is disabled.  If I try IMAP without
encryption (still using NTLM/SPA authentication), it does work in ALL cases and
I can read mail.  I.e. the behaviour is the same on RHEL4 and RHEL5 for these
tests.  RHEL5/x86_64 isn't special.

Comment 13 Göran Uddeborg 2008-01-10 17:12:28 UTC
B.t.w., is really the component and Summary correct in this case?  Is really
evolution-connector involved when talking IMAP with Exchange?

Comment 14 Göran Uddeborg 2008-01-23 12:44:06 UTC
As you made me realise, my problem is probably not the same as the original
reporter's.  But in any case I think it could be worth mentioning here I think I
found the reason.  (For MY problem, that is.)

The package evolution28-evolution-connector-2.8.0-13.el4.x86_64 contains a
Bonobo file GNOME_Evolution_Exchange_Storage_2.8.server which is placed in the
directory  /usr/lib/bonobo/servers.  But on a 64 bit system it should have been
placed in /usr/lib64/bonobo/servers instead!  I tried to copy it there, and now
I CAN connect to Exchange from evolution.

Comment 15 Matthew Barnes 2008-01-23 16:47:53 UTC
Ah geez, I thought I got all that multilib stuff cleaned up.  Looks like one did
slip through.  Thanks much for spotting this!  I'll propose this for 4.7.

Comment 16 Matthew Barnes 2008-01-23 17:04:04 UTC
I opened bug #429891 for the multilib issue.

Setting this bug to NEEDINFO until someone can confirm whether the original
problem still exists in Evolution 2.8 on RHEL 4.6.  Note that I believe Exchange
servers have to be explicitly configured to allow access via POP or IMAP.

Comment 18 ritz 2008-02-03 18:10:13 UTC
oops, my bad. wrong bugzilla. 

Comment 19 Matěj Cepl 2008-03-05 23:05:49 UTC
Reporter, could you please reply to the question in comment 16? Thank you.

Comment 20 Matthew Barnes 2008-03-10 06:02:09 UTC
Closing due to lack of reponse.

Note You need to log in before you can comment on or make changes to this bug.