I suspect that there is something unusual about my setup or exchange
server setup or _something_ because obviously this is working for
others just fine.  However, I now have three people in my company who
can't get this to work, all failing in the same way: one using Red Hat
RPMs, one using Gentoo, and myself, using Garnome on a Debian Sarge
system.

So, it doesn't seem like the Connector folks will have an easy time of
it to fix this bug themselves.

I'm quite willing to do some lifting here to assist; unfortunately
while I can do some testing and while I've been programming (and
debugging) for a lot of years, I don't have time to learn the entire
application: I need some pointers from someone on the team as to where
and how to debug the problem.  Since the problem is related to login
it shouldn't be that hard to track down.

I took a quick scan through the 2.0.0 code and thought I found a place
to add some debugging.  I then tried to look at the 1.4.x code, which
works, to see what the difference was but the code was so different I
couldn't really make the same mods.

If someone could just spend 20 mins or so and send me an email with
some pointers on where to look, what to look at, etc. I'm happy to get
more info for this problem or if I'm lucky, even a fix.  Really
helpful also would be tips about how to look at the 1.4.x code for
logging in so I can try to compare and see what's different.

A few things that might help you look out for are ...

1. Try applying that ntlm patch to your openldap, since logging in
tries to query global catalog server for your email and other
information and this might fail without this patch
2. For connector 2.0, the code for logging in is in
storage/exchange-account.c:(exchange_account_connect)

Hi; thanks for the comments.

Re the NTLM patch; I thought about this but connector 1.4.7.x works
great with my current openldap.  Are you saying that something changed
in connector between 1.4.7.x and 2.0 such that while it works without
NTLM in the older version, it won't work without NTLM in the newer
version?

Re code info; thanks, looking at that function it does appear to be
directy related to my issue.  I'll poke at that.  After a lifetime
spent avoiding MS products though, I don't really have any idea what a
_correct_ connection to Evolution might look like.  That's why I was
hoping to add some debugging to my connector 1.4.7.x code to see what
the correct data would look like, so I can compare it to 2.0 and maybe
see what the difference is.  I tried looking at exchange-account.c in
1.4.7.x and it's very different, and not nearly as understandable (to
me).  Any pointers for me with this older code?


Thanks for the reply!

Yes, you need to apply that NTLM patch to your openldap sources.

For the 1.4 code, you must be looking at try_connect .. the calls in
this file are basically used as callbacks.

OK, I added the patch and rebuilt libldap.  I used ldd to verify that
evolution-exchange-storage was linking with the correct library.  This
didn't help; I get the same results.  In retrospect this is not
surprising: my colleague who is using Gentoo has openldap patched for
NTLM in his system and it didn't work.

I'll look into some other suggestions.  I instrumented the connector
2.0.2 version as you suggested, printing information in the
E2kAutoconfig structure before and after calling
e2k_autoconfig_get_context().  First, That function returns a 4, which
is E2K_AUTOCONFIG_AUTH_ERROR_TRY_DOMAIN.  The data in E2kAutoconfig
struct is:

owa_uri = 'http://<servername>/exchange/psmith/'
gc_server = '<gc-servername>'
username = 'psmith'
password = '<passwd>'
gal_limit = 500
display_name = '(null)'
email = '(null)'
account_uri = '(null)'
exchange_server = '(null)'
timezone = '(null)'
nt_domain = '(null)'
w2k_domain = '(null)'
home_uri = '(null)'
exchange_dn = '(null)'
pf_server = '(null)'
require_ntlm = no
use_ntlm = no
saw_basic = yes
saw_ntlm = yes
nt_domain_defaulted = no
gc_server_autodetected = no

So far not too suspicious (to me).  I'll try to see what connector 1.4
does.

While you are at it .. also try running exchange with E2K_DEBUG set as
explained in this link ...
http://www.gnome.org/projects/evolution/bugs.shtml

Thanks for the link to the debugging help.  I tried setting
E2K_DEBUG=5 but nothing happened.  I think maybe garnome didn't enable
debugging when it configured the connector; I'll look to see if I can
rebuild it with debugging enabled.

I decided to use ethereal to try to capture a session with 1.4.7.3
(successful) and 2.0.2 (failed) and see if I could tell the
difference.  I didn't learn too much except that it _DOES_ appear to
be some kind of username/password/etc. issue.  The reason I say that
is that the sessions look pretty similar except for the
authentication, which is encrypted with basic auth so I can't read it.
 I guess the difference must be in there.

Here's a session that worked using connector 1.4.7.3:

First I make a request:

  GET /exchange/psmith/ HTTP/1.1
  Accept-Language: en
  Translate: F
  User-Agent: Evolution/1.4.6
  Host: <EXCHANGE-SERVER>
  Content-Type: text/xml; charset=utf-8
  Connection: keep-alive

Then I get a failure:

  HTTP/1.1 401 Unauthorized
  Content-Length: 83
  Content-Type: text/html
  Server: Microsoft-IIS/6.0
  WWW-Authenticate: Negotiate
  WWW-Authenticate: NTLM
  WWW-Authenticate: Basic realm="<EXCHANGE-SERVER>"
  X-Powered-By: ASP.NET
  Date: Fri, 15 Oct 2004 21:38:36 GMT

  <html><head><title>Error</title></head><body>Error: Access is
Denied.</body></html>

Then I request again, this time with basic AUTH:

  GET /exchange/psmith/ HTTP/1.1
  Accept-Language: en
  Translate: F
  User-Agent: Evolution/1.4.6
  Host: <EXCHANGE-SERVER>
  Content-Type: text/xml; charset=utf-8
  Connection: keep-alive
  Authorization: Basic abcdefghijklmnopqrstuvwxyzabcdefghij

Now I win:

  HTTP/1.1 204 No Content
  Date: Fri, 15 Oct 2004 21:38:37 GMT
  Server: Microsoft-IIS/6.0
  X-Powered-By: ASP.NET
  Content-Length: 0
  MS-WebStorage: 6.5.7226

and from then on I'm doing things like PROPFIND, etc. passing that
auth key each time.

-------------------------

Now, in the 2.0.2 session things don't go so well; first I send:

  GET /exchange/psmith/ HTTP/1.1
  Host: <EXCHANGE-SERVER>
  Accept-Language: en
  User-Agent: Evolution/2.0.2

and again this fails:

  HTTP/1.1 401 Unauthorized
  Content-Length: 83
  Content-Type: text/html
  Server: Microsoft-IIS/6.0
  WWW-Authenticate: Negotiate
  WWW-Authenticate: NTLM
  WWW-Authenticate: Basic realm="<EXCHANGE-SERVER>"
  X-Powered-By: ASP.NET
  Date: Fri, 15 Oct 2004 23:41:01 GMT

  <html><head><title>Error</title></head><body>Error: Access is
Denied.</body></html>

So again I try with basic auth:

  GET /exchange/psmith/ HTTP/1.1
  Host: <EXCHANGE-SERVER>
  Accept-Language: en
  Authorization: Basic zyxwvutsrqpomnlkjihg
  User-Agent: Evolution/2.0.2

But this time I'm dissed:

  HTTP/1.1 401 Unauthorized
  Connection: close
  Date: Fri, 15 Oct 2004 23:41:01 GMT
  Server: Microsoft-IIS/6.0
  WWW-Authenticate: Negotiate
  WWW-Authenticate: NTLM
  WWW-Authenticate: Basic realm="<EXCHANGE-SERVER>"
  X-Powered-By: ASP.NET
  Content-Type: text/html
  Content-Length: 144
  MS-WebStorage: 6.5.7226


  <body><h2>HTTP/1.1 401 Unauthorized</h2></body></HTML>arset=utf-8">

Note that the basic auth messages in the first and second attempts
looked very different, but I guess you'd expect that.  Also note that
the 1.4.x session was all on the same TCP stream, while for the 2.0.2
session it seems to have dropped between the first authorization error
and the second (according to ethereal's "Follow TCP Stream" feature
anyway).

Another thing to note is that while I replaced the contents of the
basic auth keys I left the length the same and the second (failing)
example has a much shorter key than the first (working) example.  I
wonder if that's related?  Where (in the code) are the basic auth keys
generated?

I have similar authorization problems. Using system call trace on
evolution-exchange-storage I found out that it does not send the
domain as part of the basic authorization string when I specify
DOMAIN\user as windows username.

I did some experiments with different username settings:

DOMAIN\user or DOMAIN/user - login fails

user@w2k.qualified.domain - login OK, mail OK, no access to calendar:
When I press the calendar button in the left window it pops out
immediately and nothing happens except a message in the status line
which disappears immediately.

DOMAIN\DOMAIN\user - login OK, calendar works, mail folders visible
with number of new mails, error when trying to access any folder:
Error while Opening folder
exchange://ASDIS%5Cmei@sarek.itp.asdis.de/personal/Posteingang.
Could not connect to Evolution Exchange backend process: No such file
or directory.


Bodo

@Paul Smith:

The "key" for base authentication is not encrypted or something like
that, it's
the base64-encoded string "username:password". (That's why it's called
plaintext password in the mail account configuration.)

Look for "base64 decoder" with your favorite search engine and you
will find some web pages where you can enter a base64-string and will
get the decoded string.
With this you will see what's the difference between the longer and
the shorter
string. (Probably a missing "DOMAIN\")

Bodo

You're absolutely correct; using:

  perl -e 'use MIME::Base64; print decode_base64("<string>"),"\n";'

I can easily see that in the 1.4 version the auth string is
<DOMAIN>\<USER>:<PASSWORD>, but in the 2.0 version the auth string is
just <USER>:<PASSWORD>.

This is definitely the problem!  So, we need to find out where the
auth string is constructed and figure out why the Windows domain is
not being added properly.

Is this related/duplicate of bug 267541 ?

It's not obviously related: those are discussion login issues with the
LDAP server; here we're talking about login to the Exchange mail
server.  I doubt they're the same because using the OWA interface to
communicate with Exchange is a very different thing that using the
LDAP interface to communicate with an LDAP server.

Hopefully someone can find and fix this problem--it's keeping all Evo
users at my company stuck on 1.4, even with all the bugs :-/.  Thanks!

I am unable to get to calender or contacts, but I was able to get
access to my mail with a dirty little hack (patch attached). This does
not pretend to be a fix, but is submitted in case anyone is as
desperate to get at Exchange mail with Evo as I was.

With this I am able to enter the expected form, DOMAIN\username.

Used debian source of evolution-exchange-2.0.2-2

Created attachment 44359 [details] [review]
One liner workaround for Evo Exchange mail

Cool, I'll try this patch tomorrow.  But, if it doesn't allow
calendaring then it's not a solution we can actually use.  We can
already access email via IMAP for example; we really need Connector
because it gives us access to manage our Exchange calendars and
schedule meetings, etc.

Actually, I don't think that hack breaks the calendar. It turns out my
Evo was picking up some old settings from ~/.gconfd/saved_state. After
a restart of that daemon, I have not had any problems using Exchange
mail or calendar. Forgive me for bloating this bug report. Cheers.

I'm able to confirm that with this fix I can log in and view my mail,
view my calendar, and view other peoples' calenders.  Yay!!

I'll keep using this version and see if I run into more problems.

Thanks!

Thanks guys!
Waiting for a commit of the patch to close this.

Created attachment 44372 [details] [review]
Patch for form-based-authentication

Created a new patch for this fix and tested it on my setup here.
Submitted this for review to release team. Meanwhile, do apply this
patch to your sources and let us know if this solves the problem. 

Nice job all.

Anyone know of a RPM available with this fix built into it?  I'd
prefer to avoid building from source.

Sarfraaz Ahmed committed this patch eight days ago:

----------------------------
revision 1.20
date: 2004-11-03 13:22:50 +0000;  author: sarfraaz;  state: Exp; 
lines: +19 -3
2004-11-03  Sarfraaz Ahmed <asarfraaz@novell.com>

        * storage/exchange-account.c
(exchange_account_connect)(exchange_account_new)
        : Check if the user has provided a domain as part of the
username field and
        store it for connecting to the server using
form-based-authentication
        (finalize) : Cleanup the private member.
----------------------------

I've bugged...er, emailed...Matthew Hall <matt@ecsc.co.uk> about an
update to the Fedora RPM package which he appears to be the maintainer of.

Closing since patch has been commited to CVS

Looks like Matt updated his Exchange RPM on November 11th, 2004:

http://www.nrpms.net/downloads/

I've also filed a bug in the Fedora issue tracker to get this packaged
into their RPM:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141419

The issue had already been filed with the RedHat/Fedora folks.  The
canonical location bug for their package is:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139134

I filed a bug with Debian,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283964

Cheers!

One note: the patch attached to this bug by Sarfraaz Ahmed on 03 Nov
2004 is not correct.  If you visit the URL in the bug summary to see
what was actually checked in to CVS as a fix, that change IS correct.

Or you can use the first one-liner patch as well; that works.

Created attachment 44467 [details] [review]
The proper patch for gnome-2-8 branch

Created attachment 44468 [details] [review]
Patch for head [ 2.2 devel series ]

Thanks for pointing out the mistake Paul. The above 2 patches are
correct. Please note that the sources that were committed already had
the correct patches applied.