O365modern in server mode (docker) not working

[kosli]

I am trying to login to a MFA enabled O365 calendar account by using DavMail in server (docker, https://hub.docker.com/r/jberrenberg/davmail/) mode. As long as MFA was not enabled on the account, everything worked fine. Now that MFA is enabled, I have changed the davmail mode to O365modern. When accessing DavMail on port 80, I get asked for the password and after entering username & password I received the push notification authentication request on my mobile phone. After approving it, I see in the log of DavMail just a FAILED for that username and the browser ask me again for the username & password. The same happens if I use the CalDav URL in Thunderbird or on my mobile phone.

I even tried registering my own application with microsoft and entered it in the davmail.oauth.clientId config -> i still get the authentication push notification and the FAILED after approving the request.

Any idea what is going wrong and how to make it work?

Thanks.

[mguessan]

This may be a device authentication issue => after authentication O365 checks that client has a valid certificate. As your Docker container obviously is not registered this will not work.

Anyway, you should first find the right settings with DavMail in client mode, with O365Interactive or O365Manual.

[kosli]

Thanks @mguessan
Where do I find more information about the O365Manual mode? Does this work in "headless" mode too?
How do I make sure that davmail has a valid client certificate? I see how I can store it, but how do I create it? (http://davmail.sourceforge.net/sslsetup.html)

[mguessan]

Nope, O365Manual and O365Interactive open authentication dialogs and will thus not work in headless mode.
However this can help you find the right settings

[mguessan]

Please make sure you test in standalone mode before trying server/docker/headless mode.

You may have to use another clientId, see:
https://sourceforge.net/p/davmail/bugs/702/

Once you have it working in standalone mode, we can troubleshoot headless mode.

[rschmied]

Can we make interactive mode work on the CLI? Basically, what works for me in UI mode is the popup window that uses xdg-open to start the browser and then allows me to insert the resulting token into the window input line and finally clicking OK.

What I did is to replace xdg-open with a shell script that copies the link into a file, I open that link with my browser outside of the container and then paste the resulting token back into the DavMail UI window.

For me it would be nice if DavMail would support that "interactive" workflow in headless mode. E.g.

• print the link on stdout
• prompt the user for the token on stdin
• CLI paste / return

This way, I could run in headless mode again (running the container attached to a tty inside of tmux) and do the UI auth bits outside of the container without the need to do fancy X11 forwarding and library installation to support the UI.

[rschmied]

small correction... apparently, DavMail switches to manual mode when the proper libraries aren't installed. So in my case, I could see this:

2019-10-07 09:15:08,214 WARN  [AWT-EventQueue-0] davmail.exchange.auth.O365InteractiveAuthenticator  - Unable to load JavaFX (OpenJFX), switch to manual mode

which resulted in the "input OAUTH token" window / dialog which is perfectly fine for my workflow even though it requires the extraction of the Location header from the final POST response.

[mguessan]

Makes sense, please check latest trunk for a command line implementation of manual authentication.
Please also set davmail.mode to O365Manual, no need to try OpenJFX browser in your case.

You should probably also try to enable token persistence with:
davmail.oauth.persistToken=true

This will drastically reduce user interaction.

[rschmied]

Tried with latest trunk. However, the code in ExchanceSessionFactory.java checks if we run in headless mode and then throws an exception if auth mode is set to O365Manual or O365Interactive. At least for O365Manual, that restriction needs to be removed.

[mguessan]

Indeed, can you please test again ?

[rschmied]

thanks... one step further but no success yet.

2019-10-09 22:10:44,912 ERROR [ImapConnection-49858] davmail  - Authentication failed null
davmail.exception.DavMailException: Authentication failed null
	at davmail.exchange.auth.O365ManualAuthenticator.authenticate(O365ManualAuthenticator.java:137)
	at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:177)
	at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:93)
	at davmail.imap.ImapConnection.run(ImapConnection.java:139)
Please open the following link:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=...
 proceed through authentication steps and paste back the final url that contains authentication code (blank page)
Authentication code: 2019-10-09 22:10:44,915 ERROR [ImapConnection-49858] davmail.exchange.auth.O365ManualAuthenticator  - Authentication failed, code not available
2019-10-09 22:10:44,915 ERROR [ImapConnection-49858] davmail  - Authentication failed null
davmail.exception.DavMailException: Authentication failed null
	at davmail.exchange.auth.O365ManualAuthenticator.authenticate(O365ManualAuthenticator.java:137)
	at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:177)
	at davmail.exchange.ExchangeSessionFactory.getInstance(ExchangeSessionFactory.java:93)
	at davmail.imap.ImapConnection.run(ImapConnection.java:112)

I paste the link into the console and hit return. The string contains the code and session_state query parms. It basically is this (which worked with the dialog when pasted there, so I assume it's the right thing):

urn:ietf:wg:oauth:2.0:oob?code=somelongalphanumstring&session_state=some-uuid

I guess a bit more logging inside the getCodeFromConsole method would be useful to figure out whether it actually read the string and extracted the code. Maybe even print the extracted code again at debug level or something. Thanks again!

[rschmied]

OK. My fault. I did add the instrumentation code and build it from trunk myself to realize that I of course need a tty in the container... otherwise the readLine() will instantly return as stdin is eof. Looking good. Works for me :) Thanks!

[mguessan]

Great, thanks for your feedback => closing issue.