GNOME Bugzilla – Bug 737610
EWS Autodiscover fails with exchange 2013 / Exchange 2013 authentication attempts always fail
Last modified: 2021-05-19 11:01:06 UTC
Created attachment 287382 [details] logfile with EWS_DEBUG=2 as described above. Evolution: 3.4.4, 3.10.4, 3.12 Linux: Fedora, Ubuntu, Debian Exchange was recently upgraded from 2007 to 2013 -- since that time, attempts to use Evolution-ews to connect to exchange result in constant prompting to enter the user password, and no connection. Running: EWS_DEBUG=2 evolution >& `date +%Y%m%d%H%M%S`_evo.log shows a consistent return of: < HTTP/1.1 401 Unauthorized Trying to verify the EWS information interestingly enough results in an autodiscovery failure: Using BASIC auth (this exchange setup wants NTLM, but tried both, just in case) behaves according to [ http://msdn.microsoft.com/en-us/library/ee332364.aspx Implementing an autodiscover client in microsoft exchange], but clearly does the wrong thing: Trying: (1) webmail.example.com/ews/exchange.asmx which returns 401 Unauthorized (2) webmail.example.com/autodiscover/autodiscover.xml which returns 401 Unauthorized (3) example.com/autodiscover/autodiscover.xml which returns 401 Unauthorized (4) autodiscover.example.com/autodiscover/autodiscover.xml which returns 301Moved Permanently ... and redirects to www.example.com/autodiscover/autodiscover.xml (5) www.example.com/autodiscover/autodiscover.xml which returns 404 Not Found ... and a lovely web page offering various options to the discerning end user, all of which are utter gibberish to anything trying to use EWS. Using NTLM auth results in: (1) webmail.exchange.com/ews/exchange.asmx -> HTTP/1.1 401 Unauthorized (2) webmail.exchange.com/autodiscover/autodiscover.xml -> HTTP/1.1 401 Unauthorized (3) webmail.exchange.com/autodiscover/autodiscover.xml -> HTTP/1.1 401 Unauthorized ** (evolution:4028): WARNING **: Autodiscover failed: Code: 401 - Unexpected response from server (evolution:4028): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject' The attached log is from evo 3.4.4, but we're seeing the issue all the way up to 3.12 as well (still waiting to get logs for those).
Created attachment 287398 [details] logfile showing issue for evo 3.10.4
evo 3.10.4 also fails, but it fails slightly differently -- goes off into space and times out. (1) HTTP/1.1 2 Cannot resolve hostname (exchange.example.com) (2) HTTP/1.1 2 Cannot resolve hostname (autodiscover.exchange.example.com) (3) example.com/autodiscover/autodiscover.xml (4) autodiscover.example.com/autodiscover/autodiscover.xml HTTP/1.1 301 Moved Permanently HTTP/1.1 401 Unauthorized (5) autodiscover.example.com/autodiscover/autodiscover.xml (6) www.example.com/autodiscover/autodiscover.xml HTTP/1.1 200 OK ... at which point it goes off into space until timing out.
Thanks for bug report. I see the 3.4.4 fails (not much surprise), but the 3.10.4 succeeded. Why you didn't receive a final "URLs recognized" I cannot tell from this log, a backtrace might show it. You can get the backtrace with command like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only). The autodiscovery is done with the entered e-mail address, if the server doesn't know it, then bad luck. Could it be that you cancelled one password prompt, before the autodiscovery was initiated? The problem is that if it was cancelled, then any further attempts are also treated as cancelled, kind of "do not ask me for the password again if I cancelled it" feature. Some improvements had been done for it in the development version, but that will be released as stable in spring 2015. Current way to get re-prompted is to close the application where the prompt had been cancelled and run it again.
Backtrace 20140930144543_bt.txt from: > Current versions on fully patched Red Hat Enterprise Linux 7 are: > evolution.x86_64 3.8.5-22.el7_0.1 > evolution-data-server.x86_64 3.8.5-24.el7_0 > evolution-ews.x86_64 3.8.5-8.el7 > On fully patched Fedora 20 they are: > evolution.x86_64 3.10.4-4.fc20 > evolution-data-server.x86_64 3.10.4-5.fc20 > evolution-ews.x86_64 3.10.4-1.fc20 "the Exchange mailbox won't open. When I click on the right-pointing arrow to expand it, an error message temporarily flashes in the bottom banner area that says "Scanning folders in 'Exchange server sync.example.com' (Cancelled)" The bt includes starting evo, and going into preferences > receiving mail, and trying to get the exchange host info
Created attachment 287514 [details] backtrace as described
(In reply to comment #4) > "the Exchange mailbox won't open. When I click on the right-pointing arrow to > expand it, an error message temporarily flashes in the bottom banner area that > says "Scanning folders in 'Exchange server sync.example.com' (Cancelled)" This usually happens when the password prompt from an evolution-source-registry had been cancelled. Could you run from a console: /usr/libexec/evoltuion-source-registry and then run evolution and check what it'll do, please? note there should be killed all other evolution processes (e-calendar/e-addressbook-factory or `ps ax | grep evolution`) after running the source registry manually, otherwise there might not be shown any books or calendars. > The bt includes starting evo, and going into preferences > receiving mail, and > trying to get the exchange host info Hmm, it shows evolution idle. It makes sense due to the above behaviour (auto-cancel). There used to be a similar issue in the past, filled here in bugzilla, but I do not recall exact bug report id.
(In reply to comment #6) > This usually happens when the password prompt from an evolution-source-registry > had been cancelled. Could you run from a console: > /usr/libexec/evoltuion-source-registry > and then run evolution and check what it'll do, please? note there should be > killed all other evolution processes (e-calendar/e-addressbook-factory or > `ps ax | grep evolution`) after running the source registry manually, otherwise > there might not be shown any books or calendars. Evo goes into an unending password challenge/failure cycle once it starts.
(In reply to comment #6) Could you run from a console: > /usr/libexec/evoltuion-source-registry > and then run evolution and check what it'll do, please? note there should be > killed all other evolution processes (e-calendar/e-addressbook-factory or > `ps ax | grep evolution`) after running the source registry manually, otherwise > there might not be shown any books or calendars. I wrote too soon: [user@server ~]$ /usr/libexec/evolution-source-registry Migrating mail accounts from GConf... Migrating addressbook sources from GConf... Migrating calendar sources from GConf... Migrating task list sources from GConf... Migrating memo list sources from GConf... Registering EOutlookBackendFactory ('outlook') Registering EEwsBackendFactory ('ews') Registering EYahooBackendFactory ('yahoo') Registering EGoogleBackendFactory ('google') Registering EOwncloudBackendFactory ('owncloud') Registering ECollectionBackendFactory ('none') Adding local ('Source') Exchange: Pairing 1412093929.2689.0@server.example.net with resource global-address-list Adding 1412093929.2689.0@server.example.net ('Source_1') Adding 1412093781.9925.1@server.example.net ('Source_2') Adding vfolder ('Source_3') Adding 1412093781.9925.3@server.example.net ('Source_4') Adding 1412093781.9925.0@server.example.net ('Source_5') Adding 1412093781.9925.13@server.example.net ('Source_6') Adding caldav-stub ('Source_7') Adding contacts-stub ('Source_8') Adding google-stub ('Source_9') Adding ldap-stub ('Source_10') Adding local-stub ('Source_11') Adding weather-stub ('Source_12') Adding webcal-stub ('Source_13') Adding webdav-stub ('Source_14') Adding birthdays ('Source_15') Adding sendmail ('Source_16') Adding system-address-book ('Source_17') Adding system-calendar ('Source_18') Adding system-memo-list ('Source_19') Adding system-task-list ('Source_20') module-cache-reaper-Message: Scanning data directories module-cache-reaper-Message: Scanning cache directories Server is up and running... AUTH (1412099981.9925.1@server.example.net): Initiated Bus name 'org.gnome.evolution.dataserver.Sources2' acquired. Saving 1412099981.9925.1@server.example.net : [Data Source] : DisplayName=Exchange : Enabled=true : Parent= : : [Offline] : StaySynchronized=false : : [Authentication] : Host= : Method=none : Port=0 - : RememberPassword=true + : RememberPassword=false : User=user : : [Collection] : BackendName=ews : CalendarEnabled=true : ContactsEnabled=true : Identity=user : MailEnabled=true : : [Security] : Method=none : : [Ews Backend] : FilterInbox=true : CheckAll=false : Email=user@example.com : FilterJunk=false : FilterJunkInbox=false : FoldersInitialized=false : GalUid=1412099999.2689.0@server.example.net : Hosturl=https://sync.example.com/EWS/Exchange.asmx : Oaburl=https://sync.example.com/oab/319318c0-8707-4abb-9377-4e587c0d43e9/ : OabOffline=false : OalSelected= : Timeout=120 : UseImpersonation=false : ImpersonateUser= : ** Failed to load key file at 'file:///home/user/.config/evolution/sources/.goutputstream-RNR2MX': File must have a '.source' extension AUTH (1412093781.9925.1@server.example.net): Complete (DISMISSED) AUTH (1412093781.9925.1@server.example.net): Initiated AUTH (1412093781.9925.1@server.example.net): Complete (DISMISSED)
(In reply to comment #8) > AUTH (1412093781.9925.1@server.example.net): Complete (DISMISSED) This means that the source registry thinks that the password prompt had been cancelled (by the user). Any consecutive tries auto-cancel the request, if the previous one had been cancelled. I tried with RHEL7 versions: evolution-data-server-3.8.5-23.el7.1.x86_64 evolution-3.8.5-21.el7.1.x86_64 evolution-ews-3.8.5-8.el7.x86_64 libsoup-2.42.2-3.el7.x86_64 and I can connect to an Exchange 2013 server with an account directly configured in evolution and in GNOME Online Accounts. I rebooted the machine and I was asked for a password right after login. I did not cancel it, but enter it and it worked again. I would check in Seahorse whether your Login/Default keyring is properly unlocked after login.
As I guess it is a libsoup NTLM problem. it may be related to bug 736554.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/ Thank you for your understanding and your help.