This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 431663 - [RHEL5.2] Evolution always asks for password for Global Address List
[RHEL5.2] Evolution always asks for password for Global Address List
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evolution-connector (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Matthew Barnes
desktop-bugs@redhat.com
: OtherQA, Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-06 04:15 EST by Christian Jung
Modified: 2008-05-21 11:19 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2008-0361
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 11:19:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 500389 None None None Never

  None (edit)
Description Christian Jung 2008-02-06 04:15:37 EST
Description of problem:
After configuring evolution to use an exchange server and a Global address list,
evolution always asks for GAL password.

Checking the option "Remeber this password" has no effect for GAL.

Version-Release number of selected component (if applicable):
evolution-data-server-1.12.3-2.el5
evolution-2.12.3-1.el5
evolution-connector-2.12.3-2.el5
evolution-webcal-2.7.1-6

How reproducible:
always

Steps to Reproduce:
1. Configure Evolution with Exchange Server
2. Configure Global Address List:
   Menu Edit, Settings, Mail account, Receiving Options
3. work with evolution, eg. write a new email, open the address book, search for
contacs,...
  
Actual results:
Evolution asks for Exchange password

Expected results:
Evolution should use this password at least for the current session. If the
checkbox "Remember this password" is used, Evolution should never ask for this
password again.

Additional info:
Comment 1 Matthew Barnes 2008-02-06 13:35:02 EST
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.
Comment 5 Matthew Barnes 2008-02-25 10:18:20 EST
Possibly related:
http://bugzilla.gnome.org/show_bug.cgi?id=500389
Comment 6 Matthew Barnes 2008-02-25 10:44:07 EST
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
Comment 8 Matthew Barnes 2008-02-25 11:29:37 EST
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...
Comment 10 Matthew Barnes 2008-02-26 14:08:31 EST
(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.
Comment 13 Matthew Barnes 2008-02-27 11:25:50 EST
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.
Comment 15 Matthew Barnes 2008-03-04 13:48:53 EST
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!
Comment 16 Matthew Barnes 2008-03-04 14:34:14 EST
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.
Comment 17 Matthew Barnes 2008-03-04 14:40:23 EST
Christian, quick test -- try changing the user name on your Exchange account to
include your Windows domain (DOMAIN\cbolz) and see if that helps.
Comment 18 Christian Jung 2008-03-05 04:38:49 EST
I already tried that, but it didn't change anything. 
Comment 19 Matthew Barnes 2008-03-05 16:18:38 EST
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.
Comment 20 Matthew Barnes 2008-03-07 21:02:47 EST
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.
Comment 23 RHEL Product and Program Management 2008-03-12 10:59:24 EDT
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.
Comment 26 Matthew Barnes 2008-03-25 17:40:16 EDT
Fixed in evolution-data-server-1.12.3-6.el5.
Comment 32 errata-xmlrpc 2008-05-21 11:19:03 EDT
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

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