Thanks for a bug report. What are the samba packages you've installed, please? You can run this command to get the list of them:

   $ rpm -qa samba*

I updated mine to 4.3.8-0, but I'm still able to connect to my exhcnage2013 server using NTLM authentication. What authentication method are you using, please?

Getting the log is rather simple, run evolution from the command line like this:

   $ EWS_DEBUG=2 evolution &>log.txt

and the log will be saved in the log.txt file.

The evolution-ews doesn't depend on the samba, not directly, thus the connection between working and non-working evolution-ews is surprising. I didn't have installed samba-winbind-clients, which provides /usr/bin/ntml_auth, which can be used for the NTLM authentication, but still no luck, I can connect to my server.

(In reply to Milan Crha from comment #1)
> I didn't have installed samba-winbind-clients, which provides
> /usr/bin/ntml_auth, which can be used for the NTLM authentication, but still
> no luck, I can connect to my server.

Aha, this required the restart. With it restarted I can reproduce the issue, my evolution-ews fails to connect to the Exchange server.

Uninstalling the samba-winbind-clients makes it work again.

Hi Milan,

thanks for your reply.
I'm using NTLM and these are my packages:

libsmbclient-4.3.8-0.fc23.x86_64
libwbclient-4.3.8-0.fc23.x86_64
samba-client-4.3.8-0.fc23.x86_64
samba-client-libs-4.3.8-0.fc23.x86_64
samba-common-4.3.8-0.fc23.noarch
samba-common-libs-4.3.8-0.fc23.x86_64
samba-common-tools-4.3.8-0.fc23.x86_64
samba-libs-4.3.8-0.fc23.x86_64
samba-winbind-4.3.8-0.fc23.x86_64
samba-winbind-clients-4.3.8-0.fc23.x86_64
samba-winbind-modules-4.3.8-0.fc23.x86_64

I'll provide a debug log (if still needed) after stripping sensitive data.

Regards

Phil

I just tried and if I rename /usr/bin/ntlm_auth and restart evolution processes then it'll start working again. The thing is that libsoup uses this binary for the NTLM when available (and probably fallbacks to its own implementation, when it's missing; I do not know precisely, the libsoup's NTLM authentication code is too confusing for me).

Indeed, many changes were made in samba 4.3.8 also regarding ntlm, so maybe it became incompatible with exchange2013.

I think I can live with your workaround for a while ;)

I just ran into this myself.  I also tried re-creating the Exchange mail account in Evolution and and when I click "Fetch URL", it gives me an error message about

Autodiscovery query failed, the reported error was "401 Unauthorized"

Here's the output on the console from running EWSDEBUG=1 evolution and clicking "Fetch URL":

openjdk version "1.8.0_77"
OpenJDK Runtime Environment (build 1.8.0_77-b03)
OpenJDK 64-Bit Server VM (build 25.77-b03, mixed mode)

(evolution:11255): Gtk-CRITICAL **: gtk_notebook_reorder_child: assertion 'list != NULL' failed
Working around libsoup bug with redirect
autodiscover.xml:18: parser error : Opening and ending tag mismatch: link line 13 and head
</head>
      ^
autodiscover.xml:43: parser error : Opening and ending tag mismatch: img line 42 and a
            </a>
                ^
autodiscover.xml:44: parser error : Opening and ending tag mismatch: a line 41 and div
          </div>
                ^
autodiscover.xml:50: parser error : Opening and ending tag mismatch: div line 21 and body
</body>
      ^
autodiscover.xml:51: parser error : Opening and ending tag mismatch: body line 19 and html
autodiscover.xml:51: parser error : Premature end of data in tag link line 12
autodiscover.xml:51: parser error : Premature end of data in tag link line 11
autodiscover.xml:51: parser error : Premature end of data in tag meta line 7
autodiscover.xml:51: parser error : Premature end of data in tag meta line 5
autodiscover.xml:51: parser error : Premature end of data in tag meta line 4
autodiscover.xml:51: parser error : Premature end of data in tag head line 3
autodiscover.xml:51: parser error : Premature end of data in tag html line 2




For the moment, my solution was to downgrade samba by running

dnf downgrade libwbclient --allowerasing

but since the 4.3.6 packages have vanished from the repos, it downgraded all the way back to 4.3.0, which isn't great.

Can someone find out the options which are passed to ntlm_auth an run it manually with a debug level 10 to see what is failing exactly?

Hi,

ntlm_auth is run with  --helper-protocol ntlmssp-client-1 --use-cached-creds --username myusername

According to strace, I get the following dialogue between evolution and ntlm_auth:

send: YR (yo, refresh!)
receive: YR + base64 encoded NTLMSSP + base64 encoded stuff
send: TT + a challenge packet (try this)
receive: PW 
(ntlm_auth terminates)

Regards

Phil

FWIW the old samba behaviour differs:

send: YR
receive: PW
reveive: could not obtain winbind separator
... dies.

I think that's the point where evolution chooses to fallback to its own ntlm mechanism.

Can you run the ntlm_auth command manually and add -d10 so we get debug output?

(In reply to Phil from comment #9)
> I think that's the point where evolution chooses to fallback to its own ntlm
> mechanism.

Strictly speaking, it's not the evolution, but libsoup, which calls the ntlm_auth and all things around that.

I tried with that -d10 here and I see this with a working samba (4.3.0-0.1.rc4):

>  doing parameter cups options = raw
>  pm_process() returned Yes
>  lp_servicenumber: couldn't find homes
>  could not obtain winbind domain name!
>  YR TlRMTVNTUAABAAAABYIIYgAAAAAoAAAAAAAAACgAAAAGAQAAAAAADw==
>  Got 'YR TlRMTVNTUAABAAAABYIIYgAAAAAoAAAAAAAAACgAAAAGAQAAAAAADw==' from squid (length: 59).
>  could not obtain winbind separator!
>  Requesting password
>  PW
>  ...

and with the broken samba (4.3.8-0):

>  doing parameter cups options = raw
>  pm_process() returned Yes
>  lp_servicenumber: couldn't find homes
>  could not obtain winbind domain name!
>  YR TlRMTVNTUAABAAAABYIIYgAAAAAoAAAAAAAAACgAAAAGAQAAAAAADw==
>  Got 'YR TlRMTVNTUAABAAAABYIIYgAAAAAoAAAAAAAAACgAAAAGAQAAAAAADw==' from squid (length: 59).
>  GENSEC backend 'gssapi_spnego' registered
>  GENSEC backend 'gssapi_krb5' registered
>  GENSEC backend 'gssapi_krb5_sasl' registered
>  GENSEC backend 'spnego' registered
>  GENSEC backend 'schannel' registered
>  GENSEC backend 'naclrpc_as_system' registered
>  GENSEC backend 'sasl-EXTERNAL' registered
>  GENSEC backend 'ntlmssp' registered
>  GENSEC backend 'ntlmssp_resume_ccache' registered
>  GENSEC backend 'http_basic' registered
>  GENSEC backend 'http_ntlm' registered
>  Starting GENSEC mechanism ntlmssp
>  got NTLMSSP command 1, expected 0
>  GENSEC login failed: NT_STATUS_INVALID_PARAMETER
>  NA NT_STATUS_INVALID_PARAMETER

Created attachment 1147648 [details]
libsoup patch

fix for libsoup;

After some debugging, it seems the change on the samba side uncovered a little oversight on the libsoup side. I turned those g_warning()-s into g_debug(), because the later had been shown on the console after this failure.

*** Bug 1327253 has been marked as a duplicate of this bug. ***

*** Bug 1328198 has been marked as a duplicate of this bug. ***

libsoup-2.50.0-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-476f32d4ec

libsoup-2.54.0.1-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2629a3c48

libsoup-2.52.2-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1487ac680a

*** Bug 1328587 has been marked as a duplicate of this bug. ***

Tried out the update. I moved /usr/bin/ntlm_auth back into place, installed the update, rebooted. It works for general mail and connectivity, however I'm still hitting 401 Unauthorized when trying to query Autodiscover for the URL. Caching of the GAL returns no results, nor is there anything written into the EWS_DEBUG log; it spins for a second and then comes up empty. Periodically, I also get prompts about needing credentials for GAL and Calendar, however I click Reconnect and it goes away, but I can't utilize GAL.

Reverting to renaming /usr/bin/ntlm_auth is still a valid workaround and removes all prompts, allows the query to pass, and caches the GAL.

Testing against a hosted Exchange 2010 service; can provide an EWS_DEBUG=2 log if desired.

Thanks for the testing. I missed this part, unfortunately, though it seems to be related to the evolution-ews, because I see I can get the autodiscover response from the server when I have it run from a standalone application. The difference is that the NTLM authentication is initiated twice with the new ntlm_auth, while it was only once before the change. I'll try to find out some better fix for the libsoup to not iterate on the NTLM auth multiple times.

Okay, I figured out that the problem with the autodiscover is that it checks whether a password is needed (which is realized by polling /usr/bin/ntlm_auth and if it returns YR, then it's considered as it has some credentials), thus since the changed behaviour of the /usr/bin/ntlm_auth this "without password" detection "fails" and reports that the password is not needed, thus the autodiscovery fails with 401, due to no password. A similar reason might be for the addressbook and other parts.

(In reply to Milan Crha from comment #21)
> Okay, I figured out that the problem with the autodiscover is that it checks
> whether a password is needed 

I think you have hit the nail on the head there.

You should never "check whether a password is needed". When you are required to authenticate, you can *try* /usr/bin/ntlm_auth, and if that works then you're good. If it doesn't then you fall back to asking the user for a password. You shouldn't make that decision in advance.

This failure mode in autodiscover presumably already existed if ntlm_auth *has* credentials but they're invalid because your password has changed on the server side?

Perhaps we can just use the standard libsoup authenticator for this now that it's expected to work? Because libsoup *does* tend to get this right, and ask for a password with a callback *if/when* it needs one.

libsoup-2.54.0.1-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2629a3c48

As you said, similar to libsoup, also evolution-ews checks /usr/bin/ntlm_auth whether a password is required, while this test "fails" and it looks like the password is never needed. Even the connection fails later, the code didn't try to ask for the password, but it should.

I fixed this upstream:

Created commit 3aaf1b6 in ews master (3.21.1+) [1]
Created commit 47d2328 in ews gnome-3-20 (3.20.2+)

I will create updates for the Fedora for the time being and I'll add them to the libsoup updates.

[1] https://git.gnome.org/browse/evolution-ews/commit/?id=3aaf1b6

evolution-ews-3.20.1-2.fc24 libsoup-2.54.0.1-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2629a3c48

(In reply to Fedora Update System from comment #25)
> evolution-ews-3.20.1-2.fc24 libsoup-2.54.0.1-2.fc24 has been submitted as an
> update to Fedora 24.
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2629a3c48

I can see it for fc22 and fc24, but not for fc23.

(In reply to Mark from comment #26)
> I can see it for fc22 and fc24, but not for fc23.

That's "correct". I'm dealing with an issue of the evolution 3.18.5 not being marked for the build root, thus the build of the evolution-ews cannot find it and fails. I'm waiting for the release engineering to fix this issue, then I'll update also the Fedora 23 update.

The evolution-ews is already built, at [1], but the Fedora 23 update is locked, thus I cannot add the package there as of now. I'll do that as soon as it's unlocked (and I notice it being unlocked).

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=13743050

evolution-ews-3.18.5-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f65ea702b

libsoup-2.52.2-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1487ac680a

evolution-ews-3.20.1-2.fc24, libsoup-2.54.0.1-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b2629a3c48

evolution-ews-3.16.5-2.fc22, libsoup-2.50.0-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-476f32d4ec

Is this one somehow related to

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

although the issue isn't reported for fedora yet.

I was having the same issues.  The updated version in the Testing repository for Fedora 23 fixed the issue for me.  Thanks.

evolution-ews-3.18.5-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f65ea702b

(In reply to Mark from comment #33)
> Is this one somehow related to
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1327697
> 
> although the issue isn't reported for fedora yet.

I cannot tell for sure. For me, the ntlm_auth behaviour changed, which uncovered the bugs, one in libsoup and one in evolution-ews, both not counting with certain error states very well.

libsoup-2.52.2-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Still having this issue as of 04-28-2016:
rpms:
rpm -aq|grep samba
samba-winbind-4.3.8-0.fc23.x86_64
samba-common-4.3.8-0.fc23.noarch
samba-winbind-modules-4.3.8-0.fc23.x86_64
samba-4.3.8-0.fc23.x86_64
samba-common-tools-4.3.8-0.fc23.x86_64
samba-winbind-clients-4.3.8-0.fc23.x86_64
samba-libs-4.3.8-0.fc23.x86_64
samba-client-libs-4.3.8-0.fc23.x86_64
samba-winbind-krb5-locator-4.3.8-0.fc23.x86_64
system-config-samba-1.2.100-4.fc23.noarch
samba-common-libs-4.3.8-0.fc23.x86_64
samba-client-4.3.8-0.fc23.x86_64

rpm -aq|grep libsmb
libsmbclient-4.3.8-0.fc23.x86_64

rpm -aq|grep libwb
sssd-libwbclient-devel-1.13.4-2.fc23.x86_64
libwbclient-4.3.8-0.fc23.x86_64
sssd-libwbclient-1.13.4-2.fc23.x86_64


rpm -aq|grep soup
libsoup-2.52.2-2.fc23.x86_64
libsoup-2.52.2-2.fc23.i686

And the evolution-ews version, please? There landed a fix too.

Sorry about that.

rpm -aq|grep evolution
evolution-ews-3.18.5-1.fc23.x86_64
evolution-3.18.5.2-1.fc23.x86_64
evolution-mapi-3.18.4-1.fc23.x86_64
evolution-data-server-3.18.5-1.fc23.x86_64

dnf info evolution-ews
Last metadata expiration check: 24 days, 0:51:44 ago on Mon Apr  4 09:13:45 2016.
Installed Packages
Name        : evolution-ews
Arch        : x86_64
Epoch       : 0
Version     : 3.18.5
Release     : 1.fc23
Size        : 2.0 M
Repo        : @System
From repo   : updates
Summary     : Evolution extension for Exchange Web Services
URL         : https://wiki.gnome.org/Apps/Evolution
License     : LGPLv2
Description : This package allows Evolution to interact with Microsoft Exchange servers,
            : versions 2007 and later, through its Exchange Web Services (EWS) interface.

(In reply to David R. Fischer from comment #40)
> rpm -aq|grep evolution
> evolution-ews-3.18.5-1.fc23.x86_64

Right, the libsoup-2.52.2-2.fc23 update
  https://bodhi.fedoraproject.org/updates/FEDORA-2016-1487ac680a
requires also the evolution-ews-3.18.5-2.fc23 to make things fully work:
  https://bodhi.fedoraproject.org/updates/FEDORA-2016-1f65ea702b

I would normally add both packages into the same update, but the libsoup update had been locked for a day, then I decided to create a separate update for the evolution-ews, to get things to the users quicker.

evolution-ews-3.18.5-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

(In reply to Fedora Update System from comment #42)
> evolution-ews-3.18.5-2.fc23 has been pushed to the Fedora 23 stable
> repository. If problems still persist, please make note of it in this bug
> report.

Updated to new package and renamed '/usr/bin/ntlm_auth' back.

things seam to be working as expected.

Thanks all

evolution-ews-3.16.5-2.fc22, libsoup-2.50.0-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.