Closed Bug 2005168 Opened 7 months ago Closed 6 months ago

Thunderdbird ESR (140.6) oauth2 works with office365 mail (IMAP) but RELEASE (146) does not

Categories

(Thunderbird :: Untriaged, defect)

Product:
Thunderbird
Component:
Untriaged
Version:
Thunderbird 146
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1748416

People

(Reporter: paolo.marani, Unassigned)

Details

(Keywords: regression, regressionwindow-wanted)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

Steps to reproduce:

We have moved all internal corporate email to microsoft cloud (specific tenant), migrating all IMAP folders there using some microsoft tools.
Now, we have plenty of computers to reconfigure, but all of them using Thunderbird ESR latest (146) refuses to authenticate using the new imap server "outlook.office365.com". All thunderdbird "release" (140) appear to work flawlessy, both using OAuth2.

I know that has been a recent addition to thunderbird to support EWS Microsoft Exchange, anyway i think this should be not relevant in my context, as we are using IMAP access.

Our evidence is that connecting to outlook.office365.com fail to authenticate using esr but works using Release channel!

Actual results:

Configuration is the following
IMAP --> outlook.office365.com
Auth --> OAuth2 (SSL/TLS)
The Oauth2 popup appears arking for credentials
On Release --> It succeed to authenticate
On esr --> At every sync, auth2 html page flashes a little bit, than a window popup appear indicating "authentication failed after connecting to the server"

Expected results:

I think some changes introduced on modern authentication for microsoft exchange have caused some problems to normal oauth2 workflow, thus we can no longer configure thunderbird to work with microsoft accounts.

How can enable a log to throubleshoot oauth2 handshake with microsoft online account ?

We are currently at version 146.0 release channel, and ESR channel is at 140.5.0/140.6.0. So there seems to be inconsistency in your cited version numbers. Please clarify exactly which version is working and which is not.

And you are moving from imap to ESR?

Thanks

Flags: needinfo?(paolo.marani)

For OAuth2 logging, in the config editor set mailnews.oauth.loglevel to All. Then check the Error Console for logs.
For an IMAP log, see https://wiki.mozilla.org/MailNews:Logging

Keywords: regression, regressionwindow-wanted
Summary: Thunderdbird release (140) works with office365 mail (IMAP) but esr (164) does not → Thunderdbird release (140) works with office365 mail (IMAP) but esr (146) does not

Sorry, i have reversed by mistake release/esr versions.

ESR is 140.6 (It works)
Release is 146.0 (It fails)

I will collect all logs as suggested and I will post here to possibly figure out what is wrong with my oauth2 authentication

Flags: needinfo?(paolo.marani)

This is my console output, but I do not see any relevant info, except some javascript errors, but maybe that BSSO Telemetry contains some useful info for you.

1765467640175 addons.xpi WARN Checking C:\Program Files (x86)\Mozilla Thunderbird\distribution\extensions for addons
L’attributo window.fullScreen è deprecato e verrà rimosso in futuro. messenger.js:947:9
(intermediate value).getAttribute is not a function ExtensionParent.sys.mjs:325:38
getTopBrowsingContextId resource://gre/modules/ExtensionParent.sys.mjs:325
normalizeArgs resource://gre/modules/ExtensionParent.sys.mjs:344
InterpretGeneratorResume self-hosted:1332
AsyncFunctionNext self-hosted:800
Content-Security-Policy: Ignorato “'unsafe-inline'” in script-src: è stato specificato nonce-source o hash-source authorize
BSSO Telemetry: {"result":"Error","error":"bssoNotSupported","type":"TBAuthTelemetry","data":{"BSSO.info":"not-supported"},"traces":["BrowserSSO Initialized","window.navigator.msLaunchUri is not available for _pullBrowserSsoCookie"]} ConvergedLogin_PCore_XQ1tJBpoWFcL5smH9OaMyA2.js:13:111812
Content-Security-Policy: Ignorato “'unsafe-inline'” in script-src: è stato specificato nonce-source o hash-source authorize
BSSO Telemetry: {"result":"Error","error":"bssoNotSupported","type":"TBAuthTelemetry","data":{"BSSO.info":"not-supported"},"traces":["BrowserSSO Initialized","window.navigator.msLaunchUri is not available for _pullBrowserSsoCookie"]} ConvergedLogin_PCore_vvK-PTzZEf08bX9Djyv_hg2.js:13:111810
Questa pagina si trova in modalità Quirks. Questo potrebbe avere effetto sul layout della pagina. Per la modalità standard utilizzare “<!DOCTYPE html>”.
Me.htm
true Me.htm:1:1681
Storage access: true Me.htm:1:1955

Do exist a better way to properly format console error ?
This is my second attempt, the SSO for microsoft asked me credentials, but when confirmed the authentication failed again.

16:50:12.794 Content-Security-Policy: Ignorato “'unsafe-inline'” in script-src: è stato specificato nonce-source o hash-source authorize 16:50:13.406 BSSO Telemetry: {"result":"Error","error":"bssoNotSupported","type":"TBAuthTelemetry","data":{"BSSO.info":"not-supported"},"traces":["BrowserSSO Initialized","window.navigator.msLaunchUri is not available for _pullBrowserSsoCookie"]} ConvergedLogin_PCore_vvK-PTzZEf08bX9Djyv_hg2.js:13:111810 16:50:14.103 Questa pagina si trova in modalità Quirks. Questo potrebbe avere effetto sul layout della pagina. Per la modalità standard utilizzare “<!DOCTYPE html>”. Me.htm 16:50:14.142 true Me.htm:1:1681 16:50:14.142 Storage access: true Me.htm:1:1955 16:50:16.337 Content-Security-Policy: Ignorato “'unsafe-inline'” in script-src: è stato specificato nonce-source o hash-source authorize 16:50:16.935 BSSO Telemetry: {"result":"Error","error":"bssoNotSupported","type":"TBAuthTelemetry","data":{"BSSO.info":"not-supported"},"traces":["BrowserSSO Initialized","window.navigator.msLaunchUri is not available for _pullBrowserSsoCookie"]} ConvergedLogin_PCore_vvK-PTzZEf08bX9Djyv_hg2.js:13:111810 16:50:17.830 Questa pagina si trova in modalità Quirks. Questo potrebbe avere effetto sul layout della pagina. Per la modalità standard utilizzare “<!DOCTYPE html>”. Me.htm 16:50:17.890 true Me.htm:1:1681 16:50:17.890 Storage access: true Me.htm:1:1955

Summary: Thunderdbird release (140) works with office365 mail (IMAP) but esr (146) does not → Thunderdbird esr (140) oauth2 works with office365 mail (IMAP) but release (146) does not
Summary: Thunderdbird esr (140) oauth2 works with office365 mail (IMAP) but release (146) does not → Thunderdbird ESR (140) oauth2 works with office365 mail (IMAP) but RELEASE (146) does not
Summary: Thunderdbird ESR (140) oauth2 works with office365 mail (IMAP) but RELEASE (146) does not → Thunderdbird ESR (140.6) oauth2 works with office365 mail (IMAP) but RELEASE (146) does not

I HAVE SOLVED THE PROBLEM !!!!!!!!

Please read carefully, because this may have an impact in a lot of other customers having similar issues using oAUTH2.
If it's appropriate to route these informations on other channels, please instruct me doing so properly.

My solution was to .... TURN OFF LOCAL IIS INSTALLATION BINDED TO PORT 80 !!

When OAUTH2 is involved, usually an authorization provider is contacted in order to display user with the ogin workflow inside a web browser.
The url is specially crafted to contain a "callback" used by the provider to send back to the requester a proper validation code (or the JWT token directly, doesn't matter).

Well, it appear that the callback thunderbird is sending to microsoft authorization provider is ... localhost:80 !!!!

Thunderbird must startup a temporary web server (TCP/IP socket) on the local machine, in order to the web page is allowed to call the callback function sending proper authorization codes to the requester. This temporary listener is usually allocated in a free random (lower) port, to avoid conflict with existing services running on the same machine.

Thunderbird wrongly uses port 80 for the callback, and if IIS is actually running some listener right there, they will receive and respond to the authorization page instead of thunderbird, causing all sort of errors into the authentication sequence.

Turning off IIS on local machine the default port 80 is released, and thunderbird can take place completing authentication sequence.

Please, this must be corrected ASAP because it's leading to nasty errors, even more on developer's machine where usually IIS (or apache/tomcat/kestrell/you name it) is running for coding purposes.

The correction of the OAUTH2 authentication engine incorporated in Thunderbird is to choose a "random" free port for their callbacks, not relying on port 80.

Do you think this information deserve escalating to developers for appropriate verify ?

At this time the problem seem to be fixed, whenever i want to use thunderbird i need to keep the IIS local service off, and this is annoying at least.

Hope this helps,

Paolo Marani

Oh that is bug 1748416. Unfortunately, the port must be like the given one, as that's the value registered (and enforced) by at the provider side.

This is not in any way new though - it's been like this forever. So I don't know why you said it worked on older versions.

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Duplicate of bug: 1748416
Resolution: --- → DUPLICATE

It worked on older version, because the "cloned" machine where i have installed the older version had IIS turned off from the beginning.

I really (and I doubt) the localhost port cannot be changed because it must match a registered port. I suggest you to perform at least a simple check if the port 80 is busy on localhost, and emit a message to the user indicating that OAUTH2 cannot succeed because someone else is listening to that port. I would have immediately understood where the problem originates from without digging so hard on logs.

It's the redirection endpoint, per rfc6749#section-3.1.2. And no, it cannot be changed.

Adding such a check is bug 1748416.

You need to log in before you can comment on or make changes to this bug.