Bug 821963

Thanks for a bug report.

(In reply to comment #0)
> I'm trying to use evolution-ews to connect to a hosted exchange 2010 service
> where my email address domain is different to the exchange provider's domain.
> The problem appears to be with the authentication.
> 
> I am able to create the account manually using URLs that have worked with an
> older version of evolution-ews (3.2) in a different distro (Debian testing).

The new account editor only suggests an expected address based on your mail domain being filled. It cannot know of the special for, thus it allows you to change it to any value, though the suggested value may work for majority of users (I guess). I suppose the prefilled Host URL looked like
   https://exchange.myemail.com/EWS/Exchange.asmx
thus changing it to
   https://exchange.myprovider.com/EWS/Exchange.asmx
will make the Fetch URL function (aka autodiscovery) work as expected, if the hosted exchange server supports it.

> My username and Urls are of the form:
> Username:    me
> Host URL:    https://exchange.myprovider.com/EWS/Exchange.asmx
> OAB URL:     https://exchange.myprovider.com/OAB/<lots of letters>/oab.xml
> 
> The Fetch URL button returns "Autodiscover failed: Code: 2 - Unexpected
> response from server"

"Code 2" is SOUP_STATUS_CANT_RESOLVE, which makes sense, the "exchange.myemail.com" host probably doesn't exist.

> If I continue with the manually created account I am prompted to enter a
> password repeatedly for me on host myemail.com even though the
> Remember password box is ticked.

I suppose this is because the password didn't work. Evolution may keep the password prefilled, as it's the password you entered the last time.

If you agree with the above, then I'm pretty sure we can close this as NotABug.

Created attachment 585057 [details]
New EWS_DEBUG output

Thanks for your comments. I'm still unable to get this to work.  

I have confirmed my URLs are correct using outlook's autoconfiguration test utility.

In case I messed something up with my earlier testing I decided to start again. These are the steps I took.

1) Installed Fedora 17 on a new virtual machine
2) Applied all updates
3) Rebooted 
4) Installed EWS
5) Started evolution with EWS_DEBUG=2
6) Entered my name and email address and clicked continue
7) Selected EWS
8) Changed the username from my first name to my email address
9) Corrected the Host URL (as you described). Did not click Fetch Url
10) Entered the OAB URL that I confirmed with outlook
11) Clicked continue 3 times and then apply.
12) I was prompted for my password which I entered
13) Prompted for my password again (and again)

I notice that the box asks for my Exchange Web Services password on host myemail.com. Shouldn't it be asking for my password on host myprovider.com?

I tried editing my account and this time clicked Fetch URL. I got "Autodiscover failed: Code: 401 - Unexpected response from server".

I've also tried the Forget password menu option but that doesn't help.

I've attached the newer output from EWS_DEBUG.

Is there any thing else I can try?

I've found a recent posting on the evolution mailing list from someone who might be having the same problem, although he's using ubuntu and the development version of evolution.

http://mail.gnome.org/archives/evolution-list/2012-May/msg00105.html

You are right, it sounds like the same issue. I see from the log that the libsoup library tries to connect to the server with different NTLM tokens, but always fails. it also shows the Host: exchange.myprovider.com, thus it connects to the correct server.

I think this is part of libsoup, or maybe even lower, thus I'm CC'ing the libsoup developer for his opinion. Could you paste here your version of libsoup, glib2 and glib-networking meanwhile, please?

Dan, do you have any idea what can be wrong here, please?

The problem is most likely that the server supports accounts in multiple NT domains, and the default domain (which libsoup extracts from the server's NTLM response) is not the one that your account is in. So you need to specify the domain explicitly as part of your username, eg, "MYEMAIL\me". Or possibly just "MYEMAIL\me". Or "MYEMAILCOM\me"? Anyway, something of the form "DOMAIN\username" rather than just "username".

libsoup-2.38.1-1.fc17 (64-bit)
glib2-2.32.1-1.fc17 (64-bit)
glib-networking-2.32.1-1.fc17 (64-bit)

I've got in touch with my exchange provider who informs me that their version of exchange 2010 is a hosting version and does not provide a domain like exchange 2007 does.

I've asked if NTLM authentication is supported on this hosting version and will hopefully hear back today.

I've had a response about the NTLM authentication...

"You are connecting to an Exchange 2010 SP1 server running in /hosting mode ...

As a result normal NTLM  DOMAIN\user  login credentials that would work if connected to a standalone server environment are disabled to allow the multi-tenancy to function correctly for external web connections.

Login is therefore based on the value of the User Principal Name attribute of the AD accounts which in all cases is set to the mailbox e-mail address."

I assume it is possible to configure evolution to login this way because presumably this was how it was working a few months ago on my Debian Testing installation.  Any suggestions on how I can do this so I can try it out and hopefully close this issue?

You can change your username by editing account properties, in Edit->Preferences->Mail Accounts-><ews account>->Edit->Receiving Email tab, and there the 'Username' entry is used as a username for authentication against the server. Note that any such change in account preferences requires restart of evolution.

My original configuration then is correct with my email address as my username.

The problem, if I understand it correctly, is that Evolution is attempting to authenticate using NTLM but NTLM is not supported by Exchange 2010 when run in hosting mode (as is the case with the server I'm connecting to).

When NTLM authentication fails, should evolution automatically try a more basic form of authentication?

The whole authentication is done by libsoup itself. Maybe evolution-ews can instruct it about possible methods, but if I see correctly then it just enabled NTLM authentication and that's it. Everything else is up to the libsoup library.

I understood from your comment #8 that the server uses only different name in the NTLM authentication, it expects there email address instead of domain\username.

I suppose you still have your username set as your email address, in newer evolution; am I right? If yes,m and if older evolution-ews (also older libsoup) works with the same setup, then we may look for an issue in one of those libraries.



Dan, do you think the current libsoup is able to work as is described in comment #8, please?

If you don't specify a domain in the username when doing NTLM auth, libsoup fills in the server's default NTLM domain (which, in this case is "EXCHANGE" according to the EWS_DEBUG output), because that's almost always the right thing to do, and if it's not, we can't autodetect what else to do anyway.

You could try specifying your username as "\me" (ie, with an empty domain) I guess.

If that doesn't work, then it seems like probably the server does not support NTLM authentication for your account. (Note that if you used OWA from any even remotely modern version of Windows, it would use Negotiate/GSSAPI, not NTLM.) In that case, this would depend on someone finishing Negotiate support in libsoup (https://bugzilla.gnome.org/show_bug.cgi?id=587145).

Or (assuming evolution-ews supports it?) you could use Basic auth rather than NTLM. Just make sure you're using SSL in that case.

I've tried the username of "\me" with no success. I don't think the server supports NTLM based on what my provider said.

How do I enable Basic authentication?  The only Authentication Type choice I have on the "Receiving Email" tab in the Account Editor is "Password". If I click the "Check for supported types" button, the EWS_DEBUG=2 output just says "in query auth types" and nothing else happens.

Here [1] is a test buld, which has NTLM disabled. That is a good question with the enable of the Basic authentication, because this NTLM enablement
   /* create the SoupSession for this connection */
   priv->soup_session = soup_session_async_new_with_options (
        SOUP_SESSION_USE_NTLM, TRUE,
        SOUP_SESSION_ASYNC_CONTEXT, priv->soup_context,
        NULL);
is in the code all the time, even in Fedora 16 version (3.2.3).

Dan, how do I tell libsoup that it can actually try even other authentication methods, if the previous one (like NTLM) will not work?

Reported, could try to install a virtual machine with Fedora 16, and test with evolution-ews-3.2.3, just to make sure that this works as it should there?

http://koji.fedoraproject.org/koji/taskinfo?taskID=4095723

(In reply to comment #14)
> Dan, how do I tell libsoup that it can actually try even other
> authentication methods, if the previous one (like NTLM) will not work?

Oh, right. You can't. If NTLM is enabled, it intentionally blocks Basic. You'd have to create a new session with NTLM disabled.

(BTW, I have no idea why things worked with evolution-ews 3.2 on debian testing. The libsoup NTLM code hasn't changed in years.)

I have managed to install Fedora 16 in a virtual machine using the install DVD (for some reason the fedora 16 live cd just doesn't work on my computer). I've applied all updates and installed EWS.

I set my username to my email address and set the correct host URL just as I have done on fedora 17 and clicked Fetch URL.  It worked! 

The URLs it fetched weren't quite right.  When comparing them to the output from the Outlook EMail configuration tester it looks like it has chosen the Exchange RPC urls instead of the Exchange HTTP ones. However these were easy to correct and I was able to complete the creation of the account and view and send email.

I've attached the EWS_DEBUG=2 output up to the return of the autodiscover data. At the end after the 401 Unauthorised using NTLM authentication it then tries basic authentication.

Package versions are
evolution-3.2.3-3.fc16 (64bit)
evolution-ews-3.2.3-1.fc16 (64 bit)
libsoup-2.36.1-2.fc16 (64bit)

Created attachment 586439 [details]
EWS_DEBUG=2 output from fresh Fedora 16 install

> Authorization: Basic [me:**********]

Ugh. Right. Now I know why it worked in F16; because there was a bug in libsoup for a few releases where it *would* fall back from NTLM to Basic even though it wasn't supposed to. So NTLM was never working for you, it's just that we used to end up using Basic.

Dan, would it make sense to add an option to allow fallbacking to Basic auth into libsoup, instead of "forcing" library consumers to create new connections with a hope of a working one?

In comment #14 is a link for a scratch build for F17 which you can use for now. It should work according to your findings, please give it a try.

I've tried the package from comment 14. 

Unfortunately evolution crashed when I tried to recreate my account and clicked on the Fetch URL button. The terminal output was 

"
(evolution:2850): e-utils-CRITICAL **: ec_assistant_forward: assertion `link != NULL' failed

(evolution:2850): e-utils-CRITICAL **: ec_assistant_forward: assertion `link != NULL' failed

(evolution:2850): e-utils-CRITICAL **: ec_assistant_forward: assertion `link != NULL' failed
Working around libsoup bug with redirect

(evolution:2850): GLib-ERROR **: file gthread-posix.c: line 1158 (g_system_thread_wait): error 'Resource deadlock avoided' during 'pthread_join (pt->system_thread, NULL)'
Trace/breakpoint trap
"

However if I skip the Fetch URL bit and enter the URLs manually everything looks to be working. I can send and receive email and view contacts, calendar and tasks.

Thanks for the update. I believe the crash is fixed with another change,
namely [1]. I moved this upstream as [2]. Please see [2] for any further
updates. If possible, please CC yourself there, in case upstream developers
will have additional questions.

[1] http://git.gnome.org/browse/evolution-ews/commit/?h=gnome-3-4&id=9cd6f20a4
[2] https://bugzilla.gnome.org/show_bug.cgi?id=677007