It's working fine on my RHEL5 machine so I suspect this is a configuration issue
of some sort.  Can you try a few things for me?

1) Check how you're authenticating to the Exchange server.  I think I heard
   something from upstream about plaintext passwords not working for the GAL.

2) Check your ~/.gnome2_private/Evolution file for a "gal:" entry.

3) Run Evolution from a terminal and post any relevant-looking messages.

Possibly related:
http://bugzilla.gnome.org/show_bug.cgi?id=500389

Couple notes:

Error code 0x31 is the constant LDAP_INVALID_CREDENTIALS in openldap.

Evolution's NTLM-based LDAP authentication is contained entirely in
e2k-global-catalog.c:ntlm_bind().

Christian, can you try running Evolution from a terminal with the environment
variable E2K_DEBUG=4 defined [1], and look for messages on the terminal that
begin with "GC:".  This should tell us where in the ntlm_bind() routine the
failure is occurring.


[1] Debugging tips: http://www.gnome.org/projects/evolution/bugs.shtml

E2K_DEBUG=4 output contained this line:

GC: Could not parse NTLM bind response: 0x31

Mapping this to the ntlm_bind() logic, it appears the server is denying access
before it even challenges you to authenticate yourself.  Source control history
shows no changes to the authentication logic since at least 2005.

Authentication to Red Hat's internal Exchange 2003 server seems to work fine.

Perhaps testing with Evolution 2.8 from RHEL 5.1 would help pin down whether
this is an Evolution regression or the result of a change to the server
configuration on your side.

Either way, Evolution should be handling the authentication failure better than
just printing a cryptic warning to the terminal...

(In reply to comment #9)

Christian, thanks for the data.  Can I ask you to try this whole exercise again
with E2K_DEBUG cranked up to 5?  Need to see both 2.8 and 2.12 logs.

The E2K_DEBUG=4 logs don't show enough detail about what was sent in version 2.8
versus 2.12.  E2K_DEBUG=5 should show the actual HTTP traffic between Evolution
and OWA, and now that I know to look for the "GC:" lines in the logs it should
be easier to spot the transmissions I'm interested in.  Hopefully they'll show a
discrepancy that will help me track down what changed since 2.8.


> Question:
> - Did evo 2.8 use anonymous binds?
> - Could we add an option into evo to log into GAL with Exchange
> username/password before doing the query?

Questions best posed to the upstream maintainers.  I'm not an expert at this
authentication stuff, I'm afraid.  Especially when it comes to Exchange.

Rats.  The E2K_DEBUG=5 logs did not show the additional authentication chatter I
was hoping for.  Thanks for humoring me though.  I guess I'll have to take a
closer look at your wireshark logs and dig through the code some more.

Code snippet:

static int
connect_ldap (E2kGlobalCatalog *gc, E2kOperation *op, LDAP *ldap)
{
        ...

        /* authenticate */
#ifdef HAVE_LDAP_NTLM_BIND
        ldap_error = ntlm_bind (gc, op, ldap);
#else
        ...

        ldap_error = ldap_simple_bind_s (ldap, nt_name, gc->priv->password);

        ...
}

HAVE_LDAP_NTLM_BIND must not have been defined there in Evo 2.8.  Strange, but
at least now I have something concrete to look for.  Thanks Christian!

I'm starting to suspect this may be related to
http://bugzilla.redhat.com/show_bug.cgi?id=431663

This is a Makefile patch I added to the Fedora package in version 2.11.  The
exchange and openldap libraries were getting linked in the wrong order and our
build system suddenly started rejecting evolution-exchange builds until I fixed
this.  (I'm still not sure what made the build system suddenly hate me.)

I wonder if this issue is a side-effect of fixing the other.  The code snippet
above implies ldap_ntlm_bind() in libldap was not being properly detected in 2.8
and so it fell back to simple binds.  Unfortunately the code is structured so
the different bind methods are mutually exclusive, rather than falling back to
simple binds if NTLM binds are available and fails.

Christian, quick test -- try changing the user name on your Exchange account to
include your Windows domain (DOMAIN\cbolz) and see if that helps.

I already tried that, but it didn't change anything. 

Referring to the code snippet in comment #15, the two authentication methods are
mutually exclusive. If NTLM support is present, Evolution uses that exclusively.
Seems more reasonable to try an NTLM bind first (if available), and if that
fails fallback to the simple bind.

Need to check with the upstream guys about this first.

Posted a patch for this in the upstream bug:
http://bugzilla.gnome.org/show_bug.cgi?id=500389

Two people have confirmed it works.  The solution is suboptimal, though.  If the
global catalog server doesn't support NTLM authentication, Evolution will still
always try to connect using NTLM first and then fall back to simple binds.  A
better approach would be to allow the user to select a separate authentication
method for the global catalog server.  But alas, I can't change the UI in a RHEL
update, so this will have to do.

Devel ACK for 5.2.

This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.

Fixed in evolution-data-server-1.12.3-6.el5.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0361.html