Bug 390798

Summary: Akonadi EWS failed to authenticate with Exchange Server
Product: [Frameworks and Libraries] Akonadi Reporter: Olivier <olivier.dugeon>
Component: EWS ResourceAssignee: kdepim bugs <kdepim-bugs>
Status: CONFIRMED ---    
Severity: major CC: anders, denysmb112007, dion, dominik.schlack, francisco, frank-fischer, hujq, igitur, k, krissn, maniac, Martin, me+kde, m_louis30, nick.berg3, paolo.pedroni, petersaints, postix, vmatare+kdebug, yaohan.chen
Priority: NOR    
Version: 5.7.2   
Target Milestone: ---   
Platform: Kubuntu   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Akonadi log when creating an EWS account in kmail

Description Olivier 2018-02-20 17:58:11 UTC
Once configured Akonadi EWS plugin, clikc on "Test Connection work", but click on "OK" failed and plugin remains not connected.

Once activate kio_http debug, it seems that the NTLM handshake is correctly executed when testing the connection. Akonadi EWS try without any auth, got a 401, then try with simple NTLM v1, got 401 again, and finally try with NTLMv2 and got a 200 OK. When clicking on "OK", Akonadi EWS just try NTLMv1 and newer try NTLMv2.

It seems that this bugs is related to old NTLM problem in kio_http patched by the author of akonadi_ews plugin.

Note that same credential with Exchange or Thunderbird work fine and that using a kerberos ticket allows authentication.
Comment 1 dominik.schlack 2018-02-21 18:38:05 UTC
I can confirm this behavior, though i'm not sure the cause is the same. I found that the Password field is always empty on editing an account. Also, in kwalletmanager the akonadi folder is created, but no entrys are created. I'm not sure wether it should or not. Just something i noticed.
Also, i can confirm my account working on the same mashine with evolution-ews
Comment 2 dominik.schlack 2018-02-21 18:43:34 UTC
Also, this might be a duplicate of 390260
Comment 3 dominik.schlack 2018-02-21 18:48:25 UTC
(In reply to dominik.schlack from comment #2)
> Also, this might be a duplicate of 390260

wrong one. It's 389369
Comment 4 Christian 2018-04-05 11:56:42 UTC
I have the same issue with kdepim version 17.12.3.  The password is stored in the password dialog, and clicking on "Try connect" works - the status on the tab "Status" changes to OK then and presents the Exchange version number (in my case, 14.3.361.1 Exchange 2010 SP3).
But the "Subscription" tab shows "Failed to retrieve folder list", and when I close the dialog with OK, the account itself shows "Unable to connect to Exchange server".
If you need more info to diagnose this problem, please let me know.

Another, maybe unrelated issue - in the Evolution EWS plugin, I can login to the EWS account using my email address and password. In the akonadi plugin, I have to use a strange user name that took me a while to find in the interface of the Exchange webmail.

(In reply to Olivier from comment #0)
> Once configured Akonadi EWS plugin, clikc on "Test Connection work", but
> click on "OK" failed and plugin remains not connected.
> 
> Once activate kio_http debug, it seems that the NTLM handshake is correctly
> executed when testing the connection. Akonadi EWS try without any auth, got
> a 401, then try with simple NTLM v1, got 401 again, and finally try with
> NTLMv2 and got a 200 OK. When clicking on "OK", Akonadi EWS just try NTLMv1
> and newer try NTLMv2.
> 
> It seems that this bugs is related to old NTLM problem in kio_http patched
> by the author of akonadi_ews plugin.
> 
> Note that same credential with Exchange or Thunderbird work fine and that
> using a kerberos ticket allows authentication.
Comment 5 Anders Bolager 2018-04-24 18:08:51 UTC
I am on the latest Kubuntu (actually, still development version for the next two days) with akonadi version 17.12.3 (it claims akonadi_ews is 5.7.3) and see the same problem. The password never shows up in kwallet and "Failed to retrieve folder list." It works fine on my work computer with Kubuntu 17.04.3 and akonadi_ews 0.8.1-1.1-1.
Comment 6 Anders Bolager 2018-04-24 18:17:10 UTC
(In reply to Anders Bolager from comment #5)
> I am on the latest Kubuntu (actually, still development version for the next
> two days) with akonadi version 17.12.3 (it claims akonadi_ews is 5.7.3) and
> see the same problem. The password never shows up in kwallet entry for  and "Failed to
> retrieve folder list." It works fine on my work computer with Kubuntu
> 17.04.3 and akonadi_ews 0.8.1-1.1-1.

I also get this error message in akonadiconsole:
AgentBase(akonadi_ews_resource_2): Root folder id not known.
Comment 7 Christian 2018-04-25 11:19:55 UTC
Anders, the behaviour you mentioned with the password not being stored sounds more like bug 393002, not this bug (where the password is stored but EWS fails to connect).
Comment 8 Anders Bolager 2018-04-25 19:25:46 UTC
Christian, that may well be true. I've added some information to that bug. After manually inserting the password into kwallet (and seeing it showing up in the configuration GUI) I still cannot fetch the folder list.
Comment 9 Christian 2018-05-01 08:54:21 UTC
*** Bug 390139 has been marked as a duplicate of this bug. ***
Comment 10 Christian 2018-05-01 08:55:06 UTC
*** Bug 390799 has been marked as a duplicate of this bug. ***
Comment 11 Stefan Brüns 2018-05-03 22:38:51 UTC
Git commit a20701f5837e067496ef91954940c49eb9e15beb by Stefan Brüns.
Committed on 03/05/2018 at 22:38.
Pushed by bruns into branch 'master'.

Always add domain delimiter if "Domain" checkbox is selected

Summary:
EwsConfigDialog::fullUsername() always adds the domain delimiter when
the "Domain" checkbox is set, even if the actual domain name is empty,
while the login procedure in EwsResource::passwordRequestFinished(...)
only adds a domain delimiter if the domain is non-empty. Make sure
login in the config dialog and during normal operation is equivalent.

Not sending an (empty) domain causes login failures for some servers,
while sending it seems to be unproblematic, and can be forced off by
unselecting the checkbox.

This fixes a regression caused by commit
7c74258355cd ("EWS: Refactor server connection and password retrieval"),
which changed the check for sending the domain from mSettings->hasDomain()
to mSettings->domain().isEmpty().
Related: bug 388496

Test Plan:
Check the login from the config-dialog, once //with//, once //without//
checking "Domain"
Try to sync the resource

Reviewers: dvratil, nowicki

Reviewed By: dvratil

Subscribers: #kde_pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D12474

M  +1    -1    resources/ews/ewsresource.cpp

https://commits.kde.org/kdepim-runtime/a20701f5837e067496ef91954940c49eb9e15beb
Comment 12 Stefan Brüns 2018-05-03 22:38:51 UTC
Git commit 86302684a48fb4340facd5f773ab14556bc82219 by Stefan Brüns.
Committed on 03/05/2018 at 22:38.
Pushed by bruns into branch 'master'.

Always add domain delimiter if "Domain" checkbox is selected

Summary:
EwsConfigDialog::fullUsername() always adds the domain delimiter when
the "Domain" checkbox is set, even if the actual domain name is empty,
while the login procedure in EwsResource::passwordRequestFinished(...)
only adds a domain delimiter if the domain is non-empty. Make sure
login in the config dialog and during normal operation is equivalent.

Not sending an (empty) domain causes login failures for some servers,
while sending it seems to be unproblematic, and can be forced off by
unselecting the checkbox.

This fixes a regression caused by commit
7c74258355cd ("EWS: Refactor server connection and password retrieval"),
which changed the check for sending the domain from mSettings->hasDomain()
to mSettings->domain().isEmpty().
Related: bug 388496

Test Plan:
Check the login from the config-dialog, once //with//, once //without//
checking "Domain"
Try to sync the resource

Reviewers: dvratil, nowicki

Reviewed By: dvratil

Subscribers: #kde_pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D12474


https://commits.kde.org/kdepim-runtime/86302684a48fb4340facd5f773ab14556bc82219
Comment 13 Christian 2018-05-04 13:08:45 UTC
Stefan, thanks! I've applied that patch to kdepim-runtime 17.12.3 and it fixed my problem.
Comment 14 Anders Bolager 2018-05-04 22:02:51 UTC
I can confirm that it seems to work here too, though I did have to change version numbers from 5.8.* to 5.7.3 in some of the cmake files to get it to compile on my Ubuntu 18.04 installation. KMail also crashed a few times on a newly downloaded Office365 mail setup. I will need to move the compiled files to my work computer to really test it (still running Ubuntu 17.10) since I just set it up at home to test, but thanks a lot for your work Stefan Brüns!
Comment 15 Anders Bolager 2018-05-09 18:25:05 UTC
Crashes seems do to a strange graphics card problem.
[699755.352402] nouveau 0000:02:00.0: kmail[953]: Unknown handle 0x00000034
[699755.352413] nouveau 0000:02:00.0: kmail[953]: validate_init                                                                                                                                                                            
[699755.352416] nouveau 0000:02:00.0: kmail[953]: validate: -2                                                                                                                                                                             
[700326.206896] nouveau 0000:02:00.0: kmail[10680]: Unknown handle 0x00000035                                                                                                                                                              
[700326.206907] nouveau 0000:02:00.0: kmail[10680]: validate_init                                                                                                                                                                          
[700326.206909] nouveau 0000:02:00.0: kmail[10680]: validate: -2      
So not related to this patch.
Comment 16 Nick Berg 2018-07-24 21:28:08 UTC
What is the best way to apply this patch to fix this issue?  I am on Kubuntu 18.04.
Comment 17 Martin Steigerwald 2019-02-07 09:40:33 UTC
Hello. Olivier, thanks for the bug report and all the others for their findings about it. As Stefan committed what appears to be a fix to me quite some time ago, is the issue fixed meanwhile?
Comment 18 Olivier 2019-02-13 14:58:55 UTC
Hello Martin

I recently upgrade to latest Neon packages: 18.12.2, so kdepim 5.10.2, and performed a new test. Unfortunately, it is always the same. Only kerberos authentication works. I always got the same error 401 in the console when attempting to login with my login/password. Perhaps it is due to our version of Exchange Server.
Comment 19 Martin Steigerwald 2019-02-13 21:08:39 UTC
Olivier, thank you for confirming with newest version. What version does your Exchange server have? Can anyone else confirm it?

I am a bit puzzled about the bug report after reading through it again. I have the feeling that it is about several different issues. So or so would be helpful to have some logging / console output, when the issue happens.
Comment 20 Olivier 2019-02-15 16:20:59 UTC
Martin,

I activate debug level for ews and http (through kdebugsettings application) and made another attempt. Here it is what I got when I run akonadictl start:

org.kde.pim.ews: Setting up authentication
org.kde.pim.ews: Using password-based authentication
Empty filename passed to function
org.kde.pim.ews: Initializing authentication
org.kde.pim.ews: requestPassword: start
org.kde.pim.ews: satisfyPasswordReadRequest: got password
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Collection does not exist"
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""
org.kde.pim.ews.client.proto: "<?xml version=\"1.0\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\"><soap:Header><t:RequestServerVersion Version=\"Exchange2007_SP1\"/></soap:Header><soap:Body><m:GetFolder><m:FolderShape><t:BaseShape>IdOnly</t:BaseShape><t:AdditionalProperties><t:FieldURI FieldURI=\"folder:DisplayName\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTags\" PropertyType=\"StringArray\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTagsVersion\" PropertyType=\"Integer\"/></t:AdditionalProperties></m:FolderShape><m:FolderIds><t:DistinguishedFolderId Id=\"msgfolderroot\"/><t:DistinguishedFolderId Id=\"inbox\"/></m:FolderIds></m:GetFolder></soap:Body></soap:Envelope>\n"
org.kde.pim.ews.client.request: Starting GetFolder request ((EwsId(Distinguished: msgfolderroot), EwsId(Distinguished: inbox)))
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Collection does not exist"
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""
org.kde.pim.akonadi_indexer_agent: Failed to fetch items:  "Collection does not exist"
org.kde.pim.akonadi_indexer_agent: Indexing failed:  ""
org.kde.pim.ews.client.proto: data KIO::TransferJob(0x55587302c590) ""
org.kde.pim.ews.client.proto: response dumped to "/tmp/akonadi-ews-iTJfTtK/ews_xmldump_LBepRPi.xml"
org.kde.pim.ews.client: Failed to process EWS request - HTTP code 401
ERROR "Failed to process EWS request - HTTP code 401"
org.kde.pim.ews: requestAuthFailed - going offline

Note that the response dumped to the file "/tmp/akonadi-ews-iTJfTtK/ews_xmldump_LBepRPi.xml" is empty. You could also note that the Exchange server is version 2007_SP1, perhaps too old, but I have no possibility to change this.

Also note that, Kerberos authentication is no longer working now. To perform the test, I start by removing all EWS configuration and then recreate new one.

So, now I have no solution to access to my calendar and mail with akonadi.
Comment 21 Alexander 2019-06-11 19:58:11 UTC
Encountered this bug while setting up exchange connection. Here are debug logs from kio_http and pim.ews with username, domain, cookies and ntlm challenge/response data redacted:

org.kde.pim.ews: Setting up authentication
org.kde.pim.ews: Using password-based authentication
org.kde.pim.ews: Initializing authentication
org.kde.pim.ews: requestPassword: start
org.kde.pim.ews: requestPassword: password already set
org.kde.pim.ews.client.proto: "<?xml version=\"1.0\"?><soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:m=\"http://schemas.microsoft.com/exchange/services/2006/messages\" xmlns:t=\"http://schemas.microsoft.com/exchange/services/2006/types\"><soap:Header><t:RequestServerVersion Version=\"Exchange2007_SP1\"/></soap:Header><soap:Body><m:GetFolder><m:FolderShape><t:BaseShape>IdOnly</t:BaseShape><t:AdditionalProperties><t:FieldURI FieldURI=\"folder:DisplayName\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTags\" PropertyType=\"StringArray\"/><t:ExtendedFieldURI PropertySetId=\"9bf757ae-69b5-4d8a-bf1d-2dd0c0871a28\" PropertyName=\"GlobalTagsVersion\" PropertyType=\"Integer\"/></t:AdditionalProperties></m:FolderShape><m:FolderIds><t:DistinguishedFolderId Id=\"msgfolderroot\"/><t:DistinguishedFolderId Id=\"inbox\"/></m:FolderIds></m:GetFolder></soap:Body></soap:Envelope>\n"
org.kde.pim.ews.client.request: Starting GetFolder request ((EwsId(Distinguished: msgfolderroot), EwsId(Distinguished: inbox)))
kf5.kio.kio_http: 
kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx")
kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx")
kf5.kio.kio_http: Window Id = ""
kf5.kio.kio_http: ssl_was_in_use = ""
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: Proxy URLs: ()
kf5.kio.kio_http: TCP_NODELAY: QVariant(int, 0)
kf5.kio.kio_http: ============ Sending Header:
kf5.kio.kio_http: "POST /EWS/Exchange.asmx HTTP/1.1"
kf5.kio.kio_http: "Host: EXCHANGE_ADDR"
kf5.kio.kio_http: "Connection: keep-alive"
kf5.kio.kio_http: "User-Agent: Mozilla/5.0 (X11; Linux x86_64; English) KHTML/5.58.0 (like Gecko) Konqueror/5 KIO/5.58"
kf5.kio.kio_http: "Pragma: no-cache"
kf5.kio.kio_http: "Cache-control: no-cache"
kf5.kio.kio_http: "Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8"
kf5.kio.kio_http: "Accept-Encoding: gzip, deflate, x-gzip, x-deflate"
kf5.kio.kio_http: "Accept-Charset: utf-8,*;q=0.5"
kf5.kio.kio_http: "Accept-Language: en-US,en;q=0.9"
kf5.kio.kio_http: "Cookie: X-BackEndCookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; exchangecookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
kf5.kio.kio_http: "Content-Type: text/xml"
kf5.kio.kio_http: sent it!
kf5.kio.kio_http: sending data (size= 898 )
kf5.kio.kio_http: "Content-Length: 898"
kf5.kio.kio_http: 
kf5.kio.kio_http: ============ Received Status Response:
kf5.kio.kio_http: "HTTP/1.1 401 Unauthorized"
kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") response code:  401 previous response code: 0
kf5.kio.kio_http: wasAuthError= false isAuthError= true sameAuthError= false
kf5.kio.kio_http:  -- full response: 
"HTTP/1.1 401 Unauthorized\r\nrequest-id: 5d252ae0-ddd8-4e94-ab13-aa75e76fafa0\r\nWWW-Authenticate: Negotiate\r\nWWW-Authenticate: NTLM\r\nX-FEServer: E24\r\nDate: Tue, 11 Jun 2019 19:16:16 GMT\r\nContent-Length: 0\r\nX-Content-Type-Options: nosniff\r\nStrict-Transport-Security: max-age=31536000; includeSubDomains\r\nContent-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'\r\nX-XSS-Protection: 1; mode=block\r\nReferrer-Policy: no-referrer\r\nAccess-Control-Allow-Origin: null\r\nCache-Control: private, no-cache, no-store, must-revalidate, max-age=0\r\nExpires: 0"
kf5.kio.kio_http: Trying authentication scheme: "Negotiate"
kf5.kio.kio_http.auth: gss_init_sec_context failed: "Unspecified GSS failure.  Minor code may provide more information SPNEGO cannot find mechanisms to negotiate "
kf5.kio.kio_http: isError= true needCredentials= false forceKeepAlive= false forceDisconnect= false
kf5.kio.kio_http: Blacklisting auth "Negotiate"
kf5.kio.kio_http: Trying authentication scheme: "NTLM"
kf5.kio.kio_http: isError= false needCredentials= false forceKeepAlive= false forceDisconnect= false
kf5.kio.kio_http: "0" bytes left.
kf5.kio.kio_http: bytesReceived: 0  m_iSize: 0  Chunked: false  BytesLeft: 0
kf5.kio.kio_http: EOD received! Left = "0"
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: ============ Sending Header:
kf5.kio.kio_http: "POST /EWS/Exchange.asmx HTTP/1.1"
kf5.kio.kio_http: "Host: EXCHANGE_ADDR"
kf5.kio.kio_http: "Connection: keep-alive"
kf5.kio.kio_http: "User-Agent: Mozilla/5.0 (X11; Linux x86_64; English) KHTML/5.58.0 (like Gecko) Konqueror/5 KIO/5.58"
kf5.kio.kio_http: "Pragma: no-cache"
kf5.kio.kio_http: "Cache-control: no-cache"
kf5.kio.kio_http: "Accept: text/html, text/*;q=0.9, image/jpeg;q=0.9, image/png;q=0.9, image/*;q=0.9, */*;q=0.8"
kf5.kio.kio_http: "Accept-Encoding: gzip, deflate, x-gzip, x-deflate"
kf5.kio.kio_http: "Accept-Charset: utf-8,*;q=0.5"
kf5.kio.kio_http: "Accept-Language: en-US,en;q=0.9"
kf5.kio.kio_http: "Cookie: X-BackEndCookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; exchangecookie=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
kf5.kio.kio_http: "Content-Type: text/xml"
kf5.kio.kio_http: "Authorization: NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
kf5.kio.kio_http: sent it!
kf5.kio.kio_http: 
kf5.kio.kio_http: ============ Received Status Response:
kf5.kio.kio_http: "HTTP/1.1 401 Unauthorized"
kf5.kio.kio_http: QUrl("https://DOMAIN_NAME%5CUSERNAME@EXCHANGE_ADDR/EWS/Exchange.asmx") response code:  401 previous response code: 401
kf5.kio.kio_http: wasAuthError= true isAuthError= true sameAuthError= true
kf5.kio.kio_http:  -- full response: 
"HTTP/1.1 401 Unauthorized\r\nrequest-id: 185fe6d4-09ef-4c75-bca7-245401827487\r\nWWW-Authenticate: NTLM XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\nWWW-Authenticate: Negotiate\r\nX-FEServer: E24\r\nDate: Tue, 11 Jun 2019 19:16:16 GMT\r\nContent-Length: 0\r\nX-Content-Type-Options: nosniff\r\nStrict-Transport-Security: max-age=31536000; includeSubDomains\r\nContent-Security-Policy: script-src 'self' 'unsafe-inline' 'unsafe-eval'\r\nX-XSS-Protection: 1; mode=block\r\nReferrer-Policy: no-referrer\r\nAccess-Control-Allow-Origin: null\r\nCache-Control: private, no-cache, no-store, must-revalidate, max-age=0\r\nExpires: 0"
kf5.kio.kio_http: Trying authentication scheme: "NTLM"
kf5.kio.kio_http: looks like the user canceled the authentication dialog
kf5.kio.kio_http: Previous Response: 401
kf5.kio.kio_http: Current Response: 401
kf5.kio.kio_http: "0" bytes left.
kf5.kio.kio_http: bytesReceived: 0  m_iSize: 0  Chunked: false  BytesLeft: 0
kf5.kio.kio_http: EOD received! Left = "0"
kf5.kio.kio_http: 
kf5.kio.kio_http: keepAlive = true
kf5.kio.kio_http: 
kf5.kio.kio_http: keep alive ( 60 )
org.kde.pim.ews.client.proto: data KIO::TransferJob(0x55f70b415fa0) ""
org.kde.pim.ews.client.proto: response dumped to "/tmp/akonadi-ews-ndWdUle/ews_xmldump_QDtcEwr.xml"
org.kde.pim.ews.client: Failed to process EWS request - HTTP code 401
ERROR "Failed to process EWS request - HTTP code 401"
org.kde.pim.ews: requestAuthFailed - going offline
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: 
kf5.kio.kio_http: keepAlive = false
kf5.kio.kio_http: 
kf5.kio.kio_http: 

I didnt set up kerberos at all, I have domain, username and email set in ews resource rc, querying with dbus shows hasDomain=true and enableNTLMv2=true.

I tried to find source of this bug myself with no results, this whole thing is quite complex. What bothers me is 'looks like the user canceled the authentication dialog' line, like kio_http tries to fetch data again after getting NTLM challenge, but abandons attempt immediately. 

Versions installed: kde-frameworks/kio: 5.58.0, kde-apps/kdepim-runtime: 19.04.2, akonadi-ews-resource's about dialog shows version: 5.11.2.

Hope this helps.
Comment 22 Igor Poboiko 2020-03-20 16:10:46 UTC
Git commit 7afd99abbfa141f6e6dfbe69b01827af8f16ba27 by Igor Poboiko.
Committed on 20/03/2020 at 16:10.
Pushed by poboiko into branch 'master'.

[resources/ews] Save password to wallet

Summary:
Seems like the password entered via the UI actually never gets saved anywhere.
Just do it explicitly.
Related: bug 393002, bug 402780, bug 414789

Test Plan:
1) Try to setup EWS account using autodiscovery, using Username/Password auth
2) Set Username, Password, hit "Try connect" -> it works fine
3) Hit "OK" -> observe "Authentication failure" resource error
4) Browse `akonadi-ews` via `KWalletManager` -> it's empty
5) Apply the patch, repeat 1-4 - authentication succeeds, password entry inside wallet appears

Reviewers: dvratil, nowicki

Reviewed By: dvratil

Subscribers: kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D27813

M  +1    -0    resources/ews/ewsconfigdialog.cpp

https://commits.kde.org/kdepim-runtime/7afd99abbfa141f6e6dfbe69b01827af8f16ba27
Comment 23 Victor Mataré 2020-03-20 21:49:23 UTC
YES, the patch from 7afd99ab fixes the problem for me. I now can finally access my calendar. Thank you very much Igor!
Comment 24 Pedro Albuquerque Santos 2020-06-28 13:42:15 UTC
The fix is still no part of akonadi 20.04, is it? Will it be released as part of 20.08?

In the meantime, I found this workaround: https://github.com/KrissN/akonadi-ews/issues/48#issuecomment-370542561
Comment 25 Francisco Isgleas 2020-10-15 09:27:41 UTC
Trying to setup a new ews account, authentication is successful when testing connection but the "OK" button remains greyed out. As the configuration has not been saved to this point, the workaround has been not useful,

kdepim-runtime 20.04

QWebEngineUrlScheme::registerScheme() before installing the custom scheme handler.
org.kde.pim.ews.client: Starting OAuth2 authentication
org.kde.pim.ews.client: Launching browser for authentication
org.kde.pim.ews.client: PKeyAuth certificates not found
org.kde.pim.ews.client: Authentication succeeded
Comment 26 Christophe Marin 2020-10-16 19:36:15 UTC
(In reply to Francisco Isgleas from comment #25)

> kdepim-runtime 20.04
> 
20.04 doesn't contain Igor's commit:

% git tag --contains 7afd99ab
v20.07.80
v20.07.90
v20.08.0
v20.08.1
v20.08.2
Comment 27 Yaohan Chen 2022-03-22 02:21:23 UTC
Created attachment 147659 [details]
Akonadi log when creating an EWS account in kmail
Comment 28 Yaohan Chen 2022-03-22 02:23:21 UTC
I'm still having this problem with kdepim 22.03.80. (After completing OAuth in the browser popup, the "OK" button in the dialog remains disabled.) Attached akonadi log of my attempt to create EWS account.
Comment 29 Denys Madureira 2022-10-17 08:23:21 UTC
I can confirm that, after recent updates, the EWS service stopped to work.