After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 736554 - libsoup does not support NTLM Extended Session Security
libsoup does not support NTLM Extended Session Security
Status: RESOLVED OBSOLETE
Product: libsoup
Classification: Core
Component: Misc
2.48.x
Other Linux
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2014-09-12 09:55 UTC by E. Kastelijn
Modified: 2018-09-21 16:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Debug log (level 5) with HTTP 401 (11.99 KB, text/plain)
2014-09-12 09:55 UTC, E. Kastelijn
Details
Unmodified EWS debug log (12.18 KB, text/plain)
2014-09-13 10:02 UTC, E. Kastelijn
Details
EWS_DEBUG=2 evolution (2.67 KB, text/plain)
2014-11-27 15:11 UTC, Kevin Woldt
Details
cUrl request log (3.47 KB, text/plain)
2014-11-27 15:12 UTC, Kevin Woldt
Details
EWS_DEBUG with patch from bug 739192 applied (3.78 KB, text/plain)
2014-12-07 19:01 UTC, Kevin Woldt
Details
EWS_DEBUG with patch version 2 from bug 739192 applied (14.63 KB, text/plain)
2014-12-23 19:23 UTC, Kevin Woldt
Details

Description E. Kastelijn 2014-09-12 09:55:15 UTC
Created attachment 286016 [details]
Debug log (level 5) with HTTP 401

My Evolution EWS configuration has worked nicely for months.
Since ~2 weeks I am unable to connect to the Exchange server.
I keep getting "Password was incorrect" when I enable the EWS account.

What I tried to fix it:
* I cleared all entries in SeaHorse under "Passwords/login".
* I (re)checked my password (it works fine with Outlook & MS Lync)
* I created a debug log (see attachments)

evolution-3.10.4-3.fc20.x86_64
evolution-help-3.10.4-3.fc20.noarch
evolution-data-server-3.10.4-4.fc20.x86_64
evolution-ews-3.10.4-1.fc20.x86_64

I'd really like to fix this.
-> Can you give me a hint where to look from here or what extra info I should suplly?

kind regards,

   Egon
Comment 1 E. Kastelijn 2014-09-12 09:56:21 UTC
In Evolution I have my proxy settings on "Direct connection to the Internet".
Comment 2 David Woodhouse 2014-09-12 10:50:02 UTC
Please don't strip information from the debug log. I'd like to see all lines containing 'NTLM' in full. Your password is not contained therein.

I can't be sure because it's been mangled, but it looks like your servers might not be behaving nicely with NTLM authentication. You send a type1 packet trying to negotiate the NTLM features, and they just respond with nothing as if you didn't try to authenticate at all. But maybe that's just your editing...?

If that's really the case, you might need to switch to Negotiate auth (which is supported in 3.12).
Comment 3 E. Kastelijn 2014-09-13 10:02:39 UTC
Created attachment 286125 [details]
Unmodified EWS debug log
Comment 4 Kevin Woldt 2014-11-27 15:10:44 UTC
I can confirm the bug. I tried to send the same request with curl and succeeded. So I assume it is a problem with libsoup and NTLM. Please find attached a EWS debug log. Also attached the curl log.
Comment 5 Kevin Woldt 2014-11-27 15:11:37 UTC
Created attachment 291660 [details]
EWS_DEBUG=2 evolution
Comment 6 Kevin Woldt 2014-11-27 15:12:12 UTC
Created attachment 291661 [details]
cUrl request log
Comment 7 Kevin Woldt 2014-11-27 15:15:38 UTC
Sorry for not mention: I testet with:
gentoo 3.12.0 SMP x86_64
mail-client/evolution-3.12.7 bogofilter crypt ldap spell ssl weather -highlight -map -spamassassin
gnome-extra/evolution-data-server-3.12.7.1 gnome-online-accounts gtk introspection ipv6 kerberos ldap vala weather -api-doc-extras -test
gnome-extra/evolution-ews-3.12.7
Comment 8 David Woodhouse 2014-11-27 15:24:25 UTC
So EWS/soup is attempting this NTLM negotiation packet:

$ ~/git/siplcs/src/core/sipe_ntlm_analyzer TlRMTVNTUAABAAAABYIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAwAAAA
Base64: TlRMTVNTUAABAAAABYIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAwAAAA
Decoded 48 bytes
sip_sec_ntlm_message_describe: analyzed message is:
	NTLMSSP_NEGOTIATE_UNICODE
	NTLMSSP_REQUEST_TARGET
	NTLMSSP_NEGOTIATE_NTLM
	NTLMSSP_NEGOTIATE_ALWAYS_SIGN
	domain.len   : 0
	domain.maxlen: 0
	domain.offset: 0
	host.len   : 0
	host.maxlen: 0
	host.offset: 0
	product: 0.0.0 ()
	ntlm_revision_current: 0x00 ()

... while curl sends this:

$ ~/git/siplcs/src/core/sipe_ntlm_analyzer TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA
Base64: TlRMTVNTUAABAAAABoIIAAAAAAAAAAAAAAAAAAAAAAA
Decoded 30 bytes
sip_sec_ntlm_message_describe: analyzed message is:
	NTLMSSP_NEGOTIATE_OEM
	NTLMSSP_REQUEST_TARGET
	NTLMSSP_NEGOTIATE_NTLM
	NTLMSSP_NEGOTIATE_ALWAYS_SIGN
	NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
	domain.len   : 0
	domain.maxlen: 0
	domain.offset: 0
	host.len   : 0
	host.maxlen: 0
	host.offset: 0
	product: 0.0.0 ()
	ntlm_revision_current: 0x00 ()


The biggest difference there is that curl is using NTLMv2 extended session security. Your servers probably got configured not to accept the ancient variants of the NTLM protocol — and not before time.

I'm confused that libsoup doesn't do extended session security though. Didn't I fix that?

/me checks.... evidently not. This commit from EDS wants porting to the libsoup implementation of NTLM: https://git.gnome.org/browse/evolution-data-server/commit/?id=e31811597
Comment 9 David Woodhouse 2014-11-27 15:28:57 UTC
Note that as a short-term workaround you can use Samba/winbind to join the domain and get single-sign-on. Then Evolution and libsoup won't even *know* your password; the ntlm_auth helper tool will take care of it for them. And it *does* do NTLMv2 Extended Session Security...

I call this a 'short term workaround' but actually it's the best thing to do in a corporate Windows environment anyway. It'll make Kerberos and NTLM single-sign-on Just Work™ fairly much everywhere.
Comment 10 Kevin Woldt 2014-11-29 17:45:44 UTC
I am far away from the topic Samba/Kerberos/NTLM/... but probably you have to be on the corporate intranet for SSO and Kerberos ticket renewal, right? Then the workaround would not fit for me because I always retrieve emails from external. 

Does it help to increase the severity of the bug? Since alone in our company a large group is affected? Some of them have switched to ExQuilla or play with the idea of it. ExQuilla is known not open source.

Or is there something I can help (beside pathing libsoup)?
Comment 11 Dan Winship 2014-11-29 19:25:16 UTC
This is talking about the same thing as bug 739192, right?
Comment 12 David Woodhouse 2014-12-02 10:44:32 UTC
If I'm right in my diagnosis, then yes.
Comment 13 Dan Winship 2014-12-07 11:22:46 UTC
E. Kastelijn: can you try upgrading to the libsoup package at
http://koji.fedoraproject.org/koji/taskinfo?taskID=8318825 and see if that fixes your problem?

(Note: this is a scratch build, so it will disappear in a few days.)


Kevin Woldt: try the patch on bug 739192 ?
Comment 14 Kevin Woldt 2014-12-07 19:01:51 UTC
Created attachment 292256 [details]
EWS_DEBUG with patch from bug 739192 applied

Attached the log with the patched libsoup. The NTLM string looks a lot longer, but the server continues to answer unauthorized.
Comment 15 David Woodhouse 2014-12-07 21:06:07 UTC
It's supposed to respond with 401 Unauthorised once per exchange. What you showed there looks fine. There are two *separate* messages, each of which go through the three-packet exchange. We're still waiting for a final *response* to each message when the log terminates.
Comment 16 Kevin Woldt 2014-12-07 21:29:39 UTC
Then there must be another problem. As you can see in the log, the password prompt appears. But the prompt should not appear because the password is stored in gnome-keyring. After entering the password, the message that the password was not correct appears. I have just repeated the test and entered the password three times correctly. Every time the prompt reports it was incorrect. The log looks like the attached. There is no third exchange in the log as I understand from your comment.
Comment 17 Adam Seering 2014-12-17 04:37:18 UTC
Kevin -- try using your full standard e-mail address as your username:  "<user>@<domain>.com", not just "<user>".  Some server configurations seem to be quite picky about what format your username is presented in.  If you try a few different combinations, hopefully one will work.

(Also, don't try too many too quickly; depending on the server config, too many failed authentications in a row may lock you out.)

FYI, the NTLM blobs that you see in this log contain a fair bit of unencrypted (base64-encoded) information.  There's a Python script here that attempts to decode these blobs based (mostly) on the protocol spec released by Microsoft; you can use it to see exactly what information is being sent to/from the server, which might help you (or others) track down what's wrong:

https://gist.github.com/aseering/829a2270b72345a1dc42
Comment 18 Kevin Woldt 2014-12-23 19:23:09 UTC
Created attachment 293294 [details]
EWS_DEBUG with patch version 2 from bug 739192 applied

I patched libsoup with the second version of the patch from bug 739192. Then I changed my username to my full e-mail address. The right password is stored in gnome-keyring.
I activated the account and the password prompt appeared. After entering the password, the message that the password was not correct appears. Again, I typed the password and the same happened. So I clicked on Cancel and evolution started to synchronize the folders and the inbox.
In the debug log I could see that after the second challenge response with 401 every first request was answered with 200 and every second request was answered with 401.
Comment 19 Adam Seering 2014-12-24 15:15:55 UTC
Hm...  Well, that's partway there.

Evolution consists of multiple processes.  Run "ps ax | grep evolution"; you should see a number of them.  If you quit Evolution from the UI, you'll find that most of them continue running in the background.  Both the Evolution foreground process and some of these background processes need to be able to talk with the Exchange server, and are able to issue password prompts.

Is it possible that one of them is still using an un-patched version of libsoup (because it loaded the library into memory before you installed the patched version)?  Or that it has somehow cached the wrong authentication information?

Simple test:  Try killing off the processes (various approaches to this -- directly, "pkill -f evolution", just reboot the machine, etc), then restarting Evolution.  Does that help?
Comment 20 Kevin Woldt 2014-12-24 20:25:28 UTC
Yes, after pkilling no password prompt appears. Nice, so patch version 2 from bug 739192 fixes this bug.
Comment 21 Kevin Woldt 2015-01-15 12:23:48 UTC
The bug is also included in 2.48.1 and can be successfully patched with the patch from bug 739192.
Comment 22 Dan Winship 2015-02-10 11:57:22 UTC
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
Comment 23 E. Kastelijn 2015-06-29 18:41:58 UTC
FYI:

I updated my system from Fedora 21 to Fedora 22.
Now I am running evolution-3.16.3-2.fc22.x86_64, and the problem has gone away.
Evolution works nicely now, and does not ask for my password multiple times anymore.

kind regards,

   Egon
Comment 24 GNOME Infrastructure Team 2018-09-21 16:21:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/78.