NTLM auth broken in evolution-ews after latest samba/winbind security updates
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
evolution-ews |
Fix Released
|
High
|
|||
evolution-ews (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
After the latest security fixes to samba / winbind evolution-ews (14.04 LTS) refused to authenticate via EWS.
The upstream bug report about this can be found here:
https:/
Please integrate the fixes for libsoup and evolution-ews to Trusty to fix that problem.
Current workaround is to rename the "ntlm_auth" binary.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #2 |
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-
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #3 |
(In reply to Milan Crha from comment #1)
> I didn't have installed samba-winbind-
> /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-
In Red Hat Bugzilla #1327072, Phil (phil-redhat-bugs) wrote : | #4 |
Hi Milan,
thanks for your reply.
I'm using NTLM and these are my packages:
libsmbclient-
libwbclient-
samba-client-
samba-client-
samba-common-
samba-common-
samba-common-
samba-libs-
samba-winbind-
samba-winbind-
samba-winbind-
I'll provide a debug log (if still needed) after stripping sensitive data.
Regards
Phil
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #5 |
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).
In Red Hat Bugzilla #1327072, Phil (phil-redhat-bugs) wrote : | #6 |
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 ;)
In Red Hat Bugzilla #1327072, Garrett (garrett-redhat-bugs) wrote : | #7 |
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_
Working around libsoup bug with redirect
autodiscover.
</head>
^
autodiscover.
</a>
^
autodiscover.
</div>
^
autodiscover.
</body>
^
autodiscover.
autodiscover.
autodiscover.
autodiscover.
autodiscover.
autodiscover.
autodiscover.
autodiscover.
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.
In Red Hat Bugzilla #1327072, Andreas (andreas-redhat-bugs) wrote : | #8 |
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?
In Red Hat Bugzilla #1327072, Phil (phil-redhat-bugs) wrote : | #9 |
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
In Red Hat Bugzilla #1327072, Phil (phil-redhat-bugs) wrote : | #10 |
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.
In Red Hat Bugzilla #1327072, Andreas (andreas-redhat-bugs) wrote : | #11 |
Can you run the ntlm_auth command manually and add -d10 so we get debug output?
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #12 |
(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 TlRMTVNTUAABAAA
> Got 'YR TlRMTVNTUAABAAA
> 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 TlRMTVNTUAABAAA
> Got 'YR TlRMTVNTUAABAAA
> 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_
> 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_
> NA NT_STATUS_
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #13 |
Created attachment 1147648
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.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #14 |
*** Bug 1327253 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #15 |
*** Bug 1328198 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #16 |
libsoup-
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #17 |
libsoup-
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #18 |
libsoup-
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #19 |
*** Bug 1328587 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #1327072, Adam (adam-redhat-bugs) wrote : | #20 |
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.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #21 |
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.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #22 |
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 Red Hat Bugzilla #1327072, David (david-redhat-bugs) wrote : | #23 |
(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.
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #24 |
libsoup-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #25 |
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:/
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #26 |
evolution-
In Red Hat Bugzilla #1327072, Mark (mark-redhat-bugs) wrote : | #27 |
(In reply to Fedora Update System from comment #25)
> evolution-
> update to Fedora 24.
> https:/
I can see it for fc22 and fc24, but not for fc23.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #28 |
(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.
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #29 |
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://
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #30 |
evolution-
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #31 |
libsoup-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #32 |
evolution-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #33 |
evolution-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1327072, Mark (mark-redhat-bugs) wrote : | #34 |
Is this one somehow related to
https:/
although the issue isn't reported for fedora yet.
In Red Hat Bugzilla #1327072, David (david-redhat-bugs) wrote : | #35 |
I was having the same issues. The updated version in the Testing repository for Fedora 23 fixed the issue for me. Thanks.
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #36 |
evolution-
See https:/
instructions on how to install test updates.
You can provide feedback for this update here: https:/
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #37 |
(In reply to Mark from comment #33)
> Is this one somehow related to
>
> https:/
>
> 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.
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #38 |
libsoup-
tags: |
added: regression-update removed: regression |
tags: | added: trusty |
In Red Hat Bugzilla #1327072, David (david-redhat-bugs) wrote : | #39 |
Still having this issue as of 04-28-2016:
rpms:
rpm -aq|grep samba
samba-winbind-
samba-common-
samba-winbind-
samba-4.
samba-common-
samba-winbind-
samba-libs-
samba-client-
samba-winbind-
system-
samba-common-
samba-client-
rpm -aq|grep libsmb
libsmbclient-
rpm -aq|grep libwb
sssd-libwbclien
libwbclient-
sssd-libwbclien
rpm -aq|grep soup
libsoup-
libsoup-
In Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #40 |
And the evolution-ews version, please? There landed a fix too.
In Red Hat Bugzilla #1327072, David (david-redhat-bugs) wrote : | #41 |
Sorry about that.
rpm -aq|grep evolution
evolution-
evolution-
evolution-
evolution-
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:/
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 Red Hat Bugzilla #1327072, Milan (milan-redhat-bugs) wrote : | #42 |
(In reply to David R. Fischer from comment #40)
> rpm -aq|grep evolution
> evolution-
Right, the libsoup-
https:/
requires also the evolution-
https:/
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.
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #43 |
evolution-
In Red Hat Bugzilla #1327072, David (david-redhat-bugs) wrote : | #44 |
(In reply to Fedora Update System from comment #42)
> evolution-
> repository. If problems still persist, please make note of it in this bug
> report.
Updated to new package and renamed '/usr/bin/
things seam to be working as expected.
Thanks all
In Red Hat Bugzilla #1327072, Fedora (fedora-redhat-bugs) wrote : | #45 |
evolution-
Changed in evolution-ews: | |
importance: | Unknown → High |
status: | Unknown → Fix Released |
Description of problem: 0.1.rc4. fc23.
After updating to samba 2:4.3.8-0.fc23 I am unable to login to an exchange server anymore. No errors are logged client-side, only the password seems not to be accepted anymore.
Works fine with samba 2:4.3.6-0.fc23 and 2:4.3.0-
Version-Release number of selected component (if applicable):
evolution 3.18.5.2-1.fc23
samba 2:4.3.8-0.fc23
exchange 2013
How reproducible:
always
Steps to Reproduce:
1. upgrade samba
2. try to login to an exchange server
3. fail miserably
Actual results:
unable to login
Expected results:
able to login
Additional info:
unfortunately it is impossible for me to provide the exchange server's logs at the moment.