Open Bug 1699487 Opened 5 years ago Updated 5 days ago

OAUTH2 Authentication does not work in Office365.us GCC High Environment

Categories

(Thunderbird :: Security, enhancement)

Product:
Thunderbird
Component:
Security
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: douglas.gerdin, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

thunderbird-gcchigh-redacted.patch
2.40 KB, patch
Details | Diff | Splinter Review
account_setup.png
65.20 KB, image/png
Details
error_log.png
114.11 KB, image/png
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:86.0) Gecko/20100101 Firefox/86.0

Steps to reproduce:

Our company recently moved to the Microsoft Office365 GCC High environment for our email. In anticipation of Microsoft disabling "Basic Authentication" later this year, we are testing the use of OAUTH2 authentication. So, I set my account settings/<office365.us - account/server settings/authentication method to OAUTH2.

We have contacted Microsoft Support. They have indicated that Thunderbird must be registered in the Azure AD for us Gov. cloud. See the following:

https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-national-cloud

Microsoft indicated that Thunderbird has registered with the "commercial" AD cloud.

Actual results:

Thunderbird either doesn't respond -or- responds with message saying roughly that the selected authentication mechanism is not supported.

Expected results:

Thunderbird should have contacted our OAUTH provider which would have followed on with the expected multifactor authentication.

I'd be happy to provide any additional info from our Microsoft support ticket and additional help and information as needed.

Component: Untriaged → Security

I'm also seeing this behavior using the O365 Gov endpoints, I logged debug output and I can see Microsoft is sending AUTH=XOAUTH2 as an option but the Thunderbird client never attempts it.

As a test I tried switching the server to outlook.office365.com and it opened the ADFS sign in page for my organization. The Azure consent page is for foreign cloud application as expected since I'm using the wrong endpoint. I've tried creating an app registration in Azure for Thunderbird but that seems to be irrelevant at this point.

DEBUG LOG:
2021-05-05 15:00:41.847000 UTC - [(null) 38224: IMAP]: I/IMAP 000002A41FE2B800:outlook.office365.us:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+

2021-05-05 15:00:41.847000 UTC - [(null) 38224: IMAP]: D/IMAP SetConnectionStatus(0x0)
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=000002A428A5BC10 nb=28 needmore=0]
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: I/IMAP 000002A41FE2B800:outlook.office365.us:NA:CreateNewLineFromSocket: 1 OK CAPABILITY completed.

2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP SetConnectionStatus(0x0)
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP Try to log in
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP IMAP auth: server caps 0x800087635, pref 0x0, failed 0x0, avail caps 0x0
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
2021-05-05 15:00:41.855000 UTC - [(null) 38224: IMAP]: D/IMAP No remaining auth method
2021-05-05 15:00:41.891000 UTC - [(null) 38224: IMAP]: E/IMAP login failed entirely
2021-05-05 15:00:41.894000 UTC - [(null) 38224: IMAP]: D/IMAP SetConnectionStatus(0x80004005)

We are also seeing this behavior with Thunderbird and O365 GCC High. We had no issues with standard O365 using OAuth2. Microsoft GCC High customer support did a "fiddler" trace and claim there is a caching issue with Thunderbird. Their response below:

{

HTTP/200 responses are cacheable by default, unless Expires, Pragma, or Cache-Control headers are present and forbid caching.
Legacy Pragma Header is present: no-cache

HTTP/1.1 Cache-Control Header is present: no-store,no-cache
no-store: This response MUST NOT be stored in a cache.

HTTP/1.1 Vary Header is present: Accept-Encoding
The cache MUST contact the server to verify freshness unless the value of the headers named match those of the request that generated the cache entry.

Note: IE has limited support for Vary. See http://fiddler2.com/r/?ievary

!! WARNING: Responses which VARY should specify an ETAG to enable conditional revalidation requests.
This response contains neither an ETAG nor a Last-Modified time. This will prevent a Conditional Revalidation of this response.

This HTTP/304 response indicates that the existing cached response remains fresh. Cache-lifetime headers on a HTTP/304 response may be used to update the cached response's freshness.

Under RFC2616, HTTP/403 responses will not be cached regardless of what caching headers may be present.
This response does not specify explicit HTTP Cache Lifetime information and does not specify a Last-Modified date. Heuristic expiration is typically based on Last-Modified date. Lacking Last-Modified, this response may be revalidated on every use or once per browsing session, depending on the browser configuration.

This response contains neither an ETAG nor a Last-Modified time. This will prevent a Conditional Revalidation of this response.

================
Learn more about caching at http://fiddler2.com/r/?httpperf

I am going to get Azure involved with this since this is a third party app we are suing to connect to the service. They should hopefully be able to tell us the cause of the cashing problem that is being experienced.

Appreciate your patience on this.

HTTP/1.0 Expires Header is present: Tue, 25 Jan 2022 20:42:43 GMT

HTTP/1.1 Cache-Control Header is present: no-cache,max-age=3600
no-cache: This response MUST NOT be reused without successful revalidation with the origin server.
max-age: This resource will expire in 1 hours. [3600 sec]

HTTP/1.1 ETAG Header is present: "BjAwNAeiNkudMgjQF1LB5Pbu6nV7T4yYcMKgObt39Hs="

================
Learn more about caching at http://fiddler2.com/r/?httpperf
}

Out of curiosity I installed Thunderbird 91 in the hopes that maybe something was changed in a later build but just confirming this is still an issue 1 year later.

Just ran into this as we are progressing with our GCC High migration. This is really distressing.

We received a notice from Microsoft about the plans to disable basic auth for GCCH on March 31st, 2023. If Mozilla doesn't make a change to the endpoints (or at least offer a way to manually enter them in), we'll have to stop supporting Thunderbird as a mail client since it will no longer function.

It seems to me that once TB registered with GCC High, the following patch with the appropriate ID/secret would be all that is needed?
diff -up thunderbird-91.11.0/comm/mailnews/base/src/OAuth2Providers.jsm.gcchigh thunderbird-91.11.0/comm/mailnews/base/src/OAuth2Providers.jsm
--- thunderbird-91.11.0/comm/mailnews/base/src/OAuth2Providers.jsm.gcchigh 2022-06-27 20:40:22.000000000 -0600
+++ thunderbird-91.11.0/comm/mailnews/base/src/OAuth2Providers.jsm 2022-07-19 12:45:05.243353234 -0600
@@ -60,6 +60,20 @@ var kHostnames = new Map([
"https://outlook.office365.com/IMAP.AccessAsUser.All https://outlook.office365.com/POP.AccessAsUser.All https://outlook.office365.com/SMTP.Send offline_access",
],
],

  • [

  • "outlook.office365.us",

  • [

  •  "login.microsoftonline.us",

  •  "https://outlook.office365.us/IMAP.AccessAsUser.All https://outlook.office365.us/POP.AccessAsUser.All https://outlook.office365.us/SMTP.Send offline_access",

  • ],

  • ],

  • [

  • "smtp.office365.us",

  • [

  •  "login.microsoftonline.us",

  •  "https://outlook.office365.us/IMAP.AccessAsUser.All https://outlook.office365.us/POP.AccessAsUser.All https://outlook.office365.us/SMTP.Send offline_access",

  • ],

  • ],

    // For testing purposes.
    ["mochi.test", ["mochi.test", "test_scope"]],
    @@ -134,6 +148,17 @@ var kIssuers = new Map([
    ],
    ],

  • [

  • "login.microsoftonline.us",

  • [

  •  "XXX", // Application (client) ID

  •  "XXX", // @see App registrations | Certificates & secrets

  •  // https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols#endpoints

  •  "https://login.microsoftonline.us/common/oauth2/v2.0/authorize",

  •  "https://login.microsoftonline.us/common/oauth2/v2.0/token",

  • ],

  • ],

  • // For testing purposes.
    [
    "mochi.test",

Your comment got mangled - maybe you can update it (surround the code section with a pair of 3 single quotes).
Are you saying outlook.office365.us/login.microsoftonline.us is to be used for some environments?

This Microsoft docs page is network focused for allowing access to GCC High IP addresses, but it does also list the DNS names of the various endpoints:
https://docs.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-u-s-government-gcc-high-endpoints?view=o365-worldwide

The default commercial O365 endpoints end with .com but for GCC High they usually end with .us. Then GCC DoD has its own set of endpoint names.

I've started testing with the attached patch, and am close. I setup an app registration in my GCC High Azure portal (I've redacted the ID and secret in the patch) - I needed to make it multi-tenant and set the redirect URL to http://localhost to match the TB usage but still hit an error. Recompiling with the latest change to try to get autodiscovery to work and to allow configuring OAuth2 in the GUI.

Yes, GCC High uses office365.us and login.microsoftonline.us instead of the .com versions used by the Commercial cloud (and "regular" GCC).

I'm not sure what it would take for Mozilla to register the Thunderbird app with GCC High Azure (https://portal.azure.us). I've reached out to our vendor to see if they can find out.

If TB allowed for customization of OAuth2 configs we could work around it that way, but alas it does not.

Attached image account_setup.png —

With the latest patch I can configure OAuth2 in the GUI, but the account verification still fails. It pops up the OAuth2 window, I enter the password, then it closes.

Attached image error_log.png —

(In reply to Orion Poplawski from comment #9)

Created attachment 9286263 [details] [diff] [review]
thunderbird-gcchigh-redacted.patch

I've started testing with the attached patch, and am close. I setup an app registration in my GCC High Azure portal (I've redacted the ID and secret in the patch) - I needed to make it multi-tenant and set the redirect URL to http://localhost to match the TB usage but still hit an error. Recompiling with the latest change to try to get autodiscovery to work and to allow configuring OAuth2 in the GUI.

Yes, GCC High uses office365.us and login.microsoftonline.us instead of the .com versions used by the Commercial cloud (and "regular" GCC).

I'm not sure what it would take for Mozilla to register the Thunderbird app with GCC High Azure (https://portal.azure.us). I've reached out to our vendor to see if they can find out.

If TB allowed for customization of OAuth2 configs we could work around it that way, but alas it does not.

I work with Doug and Mabry. Mabry meant to say that this is happening with our GCC-H tenant as well. Is there anything we could do to help facilitate testing this fix?

Thanks,
Q

(In reply to Mabry Tyson from comment #12)

(In reply to Orion Poplawski from comment #9)

Created attachment 9286263 [details] [diff] [review]
thunderbird-gcchigh-redacted.patch

I've started testing with the attached patch, and am close. I setup an app registration in my GCC High Azure portal (I've redacted the ID and secret in the patch) - I needed to make it multi-tenant and set the redirect URL to http://localhost to match the TB usage but still hit an error. Recompiling with the latest change to try to get autodiscovery to work and to allow configuring OAuth2 in the GUI.

Yes, GCC High uses office365.us and login.microsoftonline.us instead of the .com versions used by the Commercial cloud (and "regular" GCC).

I'm not sure what it would take for Mozilla to register the Thunderbird app with GCC High Azure (https://portal.azure.us). I've reached out to our vendor to see if they can find out.

If TB allowed for customization of OAuth2 configs we could work around it that way, but alas it does not.

I think I'm configuring the Azure application incorrectly. (The error console is a red-herring - same errors there with a successful login). The server is responding:

AADSTS700025: Client is public so neither 'client_assertion' nor 'client_secret' should be presented.

I'm not entirely sure what is meant by "public" here. If I switch the app from multi-tenant to single-tenant I get:

Application 'aa257950-6a26-40ec-874e-ca637a48ccc2'(NWRA Thunderbird) is not configured as a multi-tenant application. Usage of the /common endpoint is not supported for such applications created after '10/15/2018'. Use a tenant-specific endpoint or configure the application to be multi-tenant.

It also seems likes TB's OAuth2 process isn't correct - what is it doing using a client_secret that clearly isn't secret?

client_secret isn't really secret in the OAuth2 spec, in the normal flow.

As of July 12, 2022, our GCC-H tenant is no longer allowing Thunderbird to access our Office365.us email. Microsoft has not confirmed that "Basic Authentication" for our environment has been disabled, but everything appears to be indicating that this is what has happened. This issue has affected all IMAP/(Basic Auth) access to Office365.us which includes client programs that are not Thunderbird.

This has left a great deal or our user base in a horrible position with respect to email. Our Linux based users have only the Outlook Web Access as an option for accessing their email.

I submitted this bug report over a year ago. I do not seem to have the power to affect the priority. Is there anything else I can do?

Could someone from Mozilla please respond? It seems like this should be a fairly simple thing to fix and it's causing us a lot of grief. Thank you

(In reply to Orion Poplawski from comment #18)

Could someone from Mozilla please respond? It seems like this should be a fairly simple thing to fix and it's causing us a lot of grief. Thank you

Check the links. It looks to me your responses are coming from about as far up the Thunderbird food chain as can be.
https://wiki.mozilla.org/Modules/Thunderbird
https://fi.linkedin.com/in/magnusmelin

Will be looking at it soon.

Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Magnus Melin [:mkmelin] from comment #20)

Will be looking at it soon.

Thank you. I'm happy to help test or in any other way if needed.

Would it help if we were able to help fund development of this?

Flags: needinfo?(sancus)

We can maybe look at this once the configuration and patch from bug 1685414 is confirmed working and on beta at least. If I'm understanding this correctly, the patch for this will just have a configuration similar to the one added in that bug, and we'll need a registration on https://portal.azure.us.(In reply to Orion Poplawski from comment #15)

It also seems likes TB's OAuth2 process isn't correct - what is it doing using a client_secret that clearly isn't secret?

Correct, there isn't supposed to be a client_secret and the new configuration has none.

Flags: needinfo?(sancus)
Depends on: 1685414

Bug 1685414 is now marked as fixed, and in the nightly builds. I thought I'd see if this bug (auth thru Office365.us) is fixed by that
It wasn't clear to me whether there's a bit more that needs to be done for this to work..

At least for me, with the most recent Daily, I am not able to log into the Office365.us to get mail. For all II know this may be peculiar to our site. I hope others will try it.

I installed Thunderbird Daily 108.0a1 (2022-10-23) (64-bit) for Mac and proceeded to set it up for our site. (I have no control over the Microsoft aspects of our site). During "Set up your existing email address", I entered first.last@example.com + name + password.

When I hit Continue, I got a pop-up "Dally tound your account setup intormation on ottice36b.us. Do you want
to proceed and submit your credentials?" I hit Login.

Now, TB Daily got confused because we apparently have a mail.example.com that answers on ports 143, 587, 993, but is not really a mail server for us. It offered a configuration using that host, but that is wrong. I had to do a manual configuration with IMAP on port 993/TLS with Normal Password on outlook.office365.us and Submission on port 587/StartTLS with Normal Password on the same host. (Those settings match what is in OWA's Settings > Mail > Sync Email)

Now, here's our potentially site specific issue: When I connect to https://outlook.office365.us/mail, another site (example.okta.com) asks for my user id (E12345) and password. When I give that, I can then find myself back at outlook.office365.us/mail and able to read my mail.

In the account configuration, I tried these usernames: E12345 (what I expect), first.last@example;.com, E12345@example.com. None of them worked.

Years back, I recall being able to trace through IMAP authentication in TB, but I couldn't easily find how to turn that debugging on again. If someone can point me to that, I can dig deeper into the authentication process to see where it breaks down.

For imap logging, see https://wiki.mozilla.org/MailNews:Logging
For OAuth2 debugging, set mailnews.oauth.loglevel to "All"

Is this really expected to be working? It's certainly not automatic. I tried with my @nwra.onmicrosoft.us email addres and it failed to find the settings for my email account. If I manually put in outlook.office365.us / smtp.office365.us and re-test it doesn't give my the option of OAuth2. If I do Advanced, then I can select OAuth2 for the IMAP server, but not for the smtp server. But in the Activity Manager, I see "The IMAP server outlook.office365.us does not support the selected authentication method." and it can't load anything and doesn't prompt me to login.

I would have thought you would have at least needed to add the OAuth2 providers in mailnews/base/src/OAuth2Providers.jsm, which I don't see. Or is there some new method to detect OAuth2 configuration?

(In reply to Mabry Tyson from comment #24)
Well at least you need to set Thunderbird to use OAuth2 for authentication, not Normal Password.

(In reply to Orion Poplawski from comment #26)
Unlikely to work yet. Needs a separate registration for outlook.office365.us

(In reply to Magnus Melin [:mkmelin] from comment #27)

(In reply to Orion Poplawski from comment #26)
Unlikely to work yet. Needs a separate registration for outlook.office365.us

Do we have any kind of estimate as to when this might be done? Thank you.

(In reply to Magnus Melin [:mkmelin] from comment #27)

(In reply to Mabry Tyson from comment #24)
Well at least you need to set Thunderbird to use OAuth2 for authentication, not Normal Password.

(In reply to Orion Poplawski from comment #26)
Unlikely to work yet. Needs a separate registration for outlook.office365.us

Can anything be done on our part to expedite the outlook.office3365.us registration?

Our company has initiated a $50/mo ongoing contribution to TB in thanks for the work done to make TB a great cross-platform email tool for our company, and to hopefully provide some more resources to tackle issues like these going forward. Unfortunately lack of GCC High support has been a big burden on our company.

Blocks: tb-ms-oauth2
Type: defect → enhancement

So, we seem to be making some progress. With 102.7.2 I can configure IMAP for outlook.office365.us with OAuth2 and it works! However, account autoconfigure sets up SMTP to be outlook.office365.us (no idea if this is really correct or not, but smtp.office365.us is an alias for it, so I think it is) but does not allow me to select OAuth2 authentication with it (or smtp.office365.us if I change the server name to that).

Ar you sure that works? I'm don't think it's possible, since outlook.office365.us isn't listed as a host in https://searchfox.org/comm-central/rev/42e044a2814aba126d0c080619e2ee247a37c39c/mailnews/base/src/OAuth2Providers.jsm#51

Re autoconfig, you can set mail.setup.loglevel to All to figure out where that value is coming from.

Duplicate of this bug: 1671616

Has there been any progress on this? This is really hampering our organization from effectively using thunderbird.

I would be willing to throw some money at getting GCC High support. Also, my org and I are willing to test fixes for this.

One problem we have is that users of Thunderbird don't get prompted to ask the administrator to allow access to the app when logging in with OAuth2. We'd usually expect to see "This is the first time this app is trying to access your tenant (or whatever), please ask your admin to allow it" And the application would appear on the admin portal to be approved. This doesn't seem to be the case with GCC High. Not sure if the Moz folks need to submit another application for GCC High or what.

After following this bug regarding a change in the way OAuth needs to be handled for protecting client secrets bug 1685414 I tried having our admin manually register a patched nightly build with the portal. Oauth2 would succeed, but when presenting the token to the imap server the imap server would not consider the token valid. I'm not sure how to get better logs of that. If I should open a new ticket for that I will.

Please advise

See Also: → 1866093

Posting this on both the Thunderbird and Davmail bug sites to hopefully help other people trying to migrate their Thunderbird configuration from office365.com to GCC-High office365.us

First, here are the succinct instructions for what eventually worked for me:

Installed DavMail 6.3.0 (allowed it to install/use the most recent Azul JRE)

Ran DavMail once (to allow it to create the ~/.davmail.properties file), closed it, added the following to the end of .davmail.properties :

davmail.tld=us

There doesn't yet appear to be a way to set that property via the front-end. I thought it might have been the "Default Windows Domain" under the "Advanced" tab, but it's not because I don't see "us" anywhere via the front-end after adding that line.

Restarted DavMail, set Exchange Protocol to O365Interactive, and set these under "Encryption":

ClientId
d3590ed6-52b3-4102-aeff-aad2292ab01c

RedirectUri
urn:ietf:wg:oauth:2.0:oob

Changed my Thunderbird server settings to point to localhost (instead of office365.com or office365.us) and the DavMail port in question (1110 in my case because I prefer POP over IMAP and that's how my current Thunderbird was setup with the previous non-gcc-high office365.com environment), set Connection Security to None, Authentication Method "Password, transmitted insecurely".

Have Thunderbird check for new messages, get prompted by Thunderbird for password, and then nothing else was needed for me. I did not get any subsequent popups, dialogs, etc from either Thunderbird or Davmail. This might have been because I was already fully authenticated (along with MFA) to the webmail frontend (https://outlook.office365.us/mail/) in a browser. Davmail most likely picked up on that. I don't yet know what will happen when I need to re-auth the MFA token, but I'm pretty confident that the worst case scenario would be that if it doesn't work directly through DavMail popups/dialogs I can just login via a browser to the webmail frontend again and it will work.

Here were the various problems I had (which will hopefully include useful keywords which will bring people here who are web-searching for specific errors, etc)

First I read over the Thunderbird bugzilla ticket for making Thunderbird compatible with GCC High:

bug 1699487

The issues people were reporting in that ticket did not seem to be the issue I was having which was:

AADSTS700016: Application with identifier '9e5f94bc-e8a4-4e73-b8be-63364c29d753' was not found in the directory '[my-company-name]'.

That GUID is the one Thunderbird uses and is publicly registered as an application in office365.com. I was told by my Azure admin that the same GUID/app does not exist in office365.us. The issues being reported by people seemed to indicate that they were having different problems that I think would only happen after the application was added to their company's Azure environment. I.e. people would have had to have gotten past my error first before they could get the errors they were currently experiencing. Perhaps it's true that Thunderbird's 9e5f94bc-e8a4-4e73-b8be-63364c29d753 application doesn't exist in office365.us, but I haven't heard a clear indication one way or the other nor did I find any specific instructions for how to guide my Azure admin to locate/add this 9e5f94bc-e8a4-4e73-b8be-63364c29d753 app in office365.us. If anyone knows it might be good to share that information so that if someone else has my issue where the Azure admin says they don't know how to add it they will have supporting details.

While I was waiting for my Azure admin to respond, I looked around for alternative solutions and saw that DavMail had a recent release [6.3.0] that specifically addressed office365 gcc-high environments. I saw this information when my searches landed me on the corresponding Davmail bug ticket:

https://github.com/mguessan/davmail/issues/284

My takeaway from reading that ticket [as of the time of this posting] was that I just needed to set the "davmail.tld=us" property, and use one of the O365Modern, O365Manual, or O365Interactive settings. None of those Exchange Protocols were working for me, though. The error I kept running into was:

AADSTS50011: The redirect URI 'https://login.microsoftonline.us/common/oauth2/nativeclient' specified in the request does not match the redirect URIs configured for the application 'facd6cff-a294-4415-b59f-c5b01937d7bd'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.

The redirect URI value would change based on what I tried, but it was always the same AADSTS50011 error code.

I tried setting my company's tenant id into the TenantId davmail setting, tried setting client id to 9199bf20-a13f-4107-85dc-02114787ef48 (because that's the id that I saw was being used while looking at the network traffic for accessing https://outlook.office365.us/mail/ in a browser), tried lots of other stuff but nothing was working. Side note - if you need to find your company's tenant ID without admin privileges, you can login to https://portal.azure.us then use the search control at the top of the page to search for "entra" which should locate the "Microsoft Entra ID" app. Launch that and you should land on your company's Overview page which should display the Tenant ID there.

I finally found this post:

https://github.com/mguessan/davmail/issues/273#issuecomment-1483851902

Which led me to use the settings noted earlier and that worked for me.

Hopefully Thunderbird will get something tweaked so that it natively works with GCC-High without DavMail as a helper. If a solution works with Thunderbird+Davmail on office365.us then it seems to me that something could be adjusted in Thunderbird to work on the same instance/configuration of office365.us without Davmail. I.e. changing/adjusting your company's office365.us/azure/gcc-high settings does not seem to be necessary. All the magic can be done client-side.

Hope this helps someone

Thank you svenork for this documentation.

CC'ing some more TB people, is this something that should be replicated on a TB documentation site?

See Also: → 1966306

With the recent EWS support landing in 145, Is there any hope for this to get onto the TB roadmap?

Hi Orion, we currently have an experimental capability to provide custom application and tenant IDs for the EWS protocol to use for its OAuth authentication. It's currently hidden behind a preference, but if you're willing to test against your GCC instance, with your own application and tenant IDs, I can send you instructions on how to enable the experimental support and input the information you need.

Flags: needinfo?(orion)
Depends on: 2002408
Depends on: 1984494

Hi All,

If you have an account on GCC or GCC High, you have your own valid Office365 Client ID, and you're willing to test an experimental capability on daily, we're in need of folks with access to those national clouds to test our experimental capability for entering custom OAuth2 client IDs, tenant IDs, and scopes to see if they work on the national cloud deployments. Here are general instructions on how to test this on GCC High:

Prerequisites:

  1. In Settings->General->Config Editor, search for the preference experimental.mail.ews.overrideOAuth.enabled.
  2. Have at least one other email account set up (so that adding a new account brings up the new Account Hub interface)
  3. Be running Thunderbird >= 147 (current daily as of the time of this writing)

Steps to try:

  1. Create a new email account (hamburger menu->New Account->EMail). You should see the account hub interface.
  2. Enter your GCC High email address.
  3. Click on the "Manual Configuration" link.
  4. Under protocol, choose "EWS".
  5. Under "EWS Endpoint URL" set "https://outlook.office365.us/EWS/Exchange.asmx". Note that the host should be adapted to your national cloud instance. For GCC High, the correct value is outlook.office365.us (see this Microsoft documentation page to verify).
  6. Under "Authentication Method" select "OAuth2".
  7. Click the "Advanced Config" link and accept the resulting dialog to confirm advanced configuration.
  8. You should be placed directly in the account settings screen for your GCC High account.
  9. In the server settings for that account click the topmost "Advanced..." button. You should get an Advanced Account Settings dialog with options to set the host URL and override Office365 settings.
  10. In the dialog, verify your URL is the correct GCC High URL.
  11. Check the "Override Office365 Settings" box.
  12. Enter your client ID in the "Application ID" Field.
  13. If you also have your own tenant, enter that into the Tenant ID field, otherwise enter "common".
  14. Set your redirect URI to "https://localhost".
  15. Set your endpoint host to the host name for your national cloud. For GCC High, this should be "login.microsoftonline.us" (see the above linked Microsoft documentation page for verification).
  16. Set the OAuth scopes field to "offline_access https://outlook.office.com/EWS.AccessAsUser.All".
  17. Press OK
  18. Go to the email account in the main part of the application and trigger a remote operation. (The easiest is to trigger a sync with the cloud/down arrow icon in the upper left).
  19. You should be presented with your Microsoft cloud login flow.
  20. Folders and emails should sync.

The Thunderbird development team does not have access to GCC High, so anyone who can test this for us in different environments will help us develop this capability further and move it from experimental to supported.

Thank you!

What build of Thunderbird should we test with?

(In reply to Kenyon Ralph from comment #42)

What build of Thunderbird should we test with?

Oops, sorry that's important information :-) I think it's best to test this with current daily, as a fix went into 147 (which is the current daily) a few weeks ago that fixed the manual account config flow. I updated the instructions above with that requirement. 147 goes to beta next week, so after next week either beta or daily should work.

I think in step 1, you meant to say set experimental.mail.ews.overrideOAuth.enabled to true. I did that, but that setting didn't make a difference for this next problem:

I tried to follow the steps with Thunderbird 147.0a1 build ID 20251202101806, but at step 6, "Authentication Method" doesn't have an "OAuth2" option, "Normal password" is the only option. If I create the account anyway, it looks like it ends up with the wrong server name, it just has .mydomain.net port 80. None of the connection security options (None, STARTTLS, SSL/TLS) allow for selecting an authentication method other than normal password.

I no longer have access to GCC High so I can't test this. But I am very interested in this working so we can move to GCC High.

I no longer have access to GCC High so I can't test this. But I am very interested in this working so we can move to GCC High.

Flags: needinfo?(orion)
Depends on: 2003842

(In reply to Kenyon Ralph from comment #44)

I think in step 1, you meant to say set experimental.mail.ews.overrideOAuth.enabled to true. I did that, but that setting didn't make a difference for this next problem:

I tried to follow the steps with Thunderbird 147.0a1 build ID 20251202101806, but at step 6, "Authentication Method" doesn't have an "OAuth2" option, "Normal password" is the only option. If I create the account anyway, it looks like it ends up with the wrong server name, it just has .mydomain.net port 80. None of the connection security options (None, STARTTLS, SSL/TLS) allow for selecting an authentication method other than normal password.

Thanks for trying! When I was testing, I used a known oauth provider, but for unknown providers (as a GCC High one will ultimately be), we hide the oauth option. I filed bug 2003842 to address this, so it looks like the instructions above are not usable until we address that issue. I put it in the current development phase as a priority, so hopefully we can get to it soon. Thanks again!

Hi All,

The next round of patches for what we discovered during the last round of testing for this have landed in today's daily (148.0a1 2025-12-18). For those of you who are interested in testing against Microsoft 365 on GCC High, here's an updated set of instructions. Thanks for bearing with us as we work through this!

Prerequisites:

  1. In Settings->General->Config Editor, search for the preference experimental.mail.ews.overrideOAuth.enabled and set it to true.
  2. Have at least one other email account set up (so that adding a new account brings up the new Account Hub interface)
  3. Be running Thunderbird >= 148.0a1-2025-12-18 (current daily as of the time of this writing)
  4. Have your own client ID for Thunderbird registered with Microsoft Entra on GCC High.

Steps to try:

  1. Create a new email account (hamburger menu->New Account->Email). You should see the account hub interface.
  2. Enter your GCC High email address.
  3. Click on the "Manual Configuration" link.
  4. Under protocol, choose "EWS".
  5. Under "EWS Endpoint URL" set "https://outlook.office365.us/EWS/Exchange.asmx". Note that the host should be adapted to your national cloud instance. For GCC High, the correct value is outlook.office365.us (see this Microsoft documentation page to verify).
  6. Under "Authentication Method" select "OAuth2".
  7. Click the "Advanced Config" link and accept the resulting dialog to confirm advanced configuration.
  8. You should be placed directly in the account settings screen for your GCC High account.
  9. In the server settings for that account click the topmost "Advanced..." button. You should get an Advanced Account Settings dialog with options to set the host URL and override Office365 settings.
  10. In the dialog, verify your URL is the correct GCC High URL.
  11. Check the "Override Office365 Settings" box.
  12. Enter your client ID in the "Application ID" Field.
  13. If you also have your own tenant, enter that into the Tenant ID field, otherwise enter "common".
  14. Set your redirect URI to the redirect URI associated with your client ID.
  15. Set your endpoint host to the host name for your national cloud. For GCC High, this should be "login.microsoftonline.us" (see the above linked Microsoft documentation page for verification).
  16. Set the OAuth scopes field to offline_access https://outlook.office.com/EWS.AccessAsUser.All.
  17. Press OK
  18. Go to the email account in the main part of the application and trigger a remote operation. (The easiest is to trigger a sync with the cloud/down arrow icon in the upper left).
  19. You should be presented with your Microsoft cloud login flow.
  20. Folders and emails should sync.

As I noted, the Thunderbird development team does not have access to GCC High, so anyone who can test this for us in different environments will help us develop this capability further and move it from experimental to supported.

Thank you so much for your help!

Testing with today's daily things seem to be basically working. I ended up using the basic redirect url of https://login.microsoftonline.com/common/oauth2/nativeclient. The main problem seems to be that what looks like an authentication windows regularly pops up and then quickly disappears, and more problematically it fairly regularly fails to authenticate and I need to re-enter my password. But it's a promising start!

Would there be a way to specify all of the needed setting in an autoconfig file? This would be very tedious to deploy manually.

Developer toolbox seems to be failing to connect to localhost so I don't have any more network details to give.

Depends on: 2008325

(In reply to Orion Poplawski from comment #49)

Testing with today's daily things seem to be basically working. I ended up using the basic redirect url of https://login.microsoftonline.com/common/oauth2/nativeclient. The main problem seems to be that what looks like an authentication windows regularly pops up and then quickly disappears, and more problematically it fairly regularly fails to authenticate and I need to re-enter my password. But it's a promising start!

Thanks for trying it out! This is the second report I've seen of this reauthentication issue, so I filed a separate issue for it: bug 2008325 .

Would there be a way to specify all of the needed setting in an autoconfig file? This would be very tedious to deploy manually.

It's at least potentially doable, but we'd probably want to define what the user experience for that looks like. We've also discussed making it easy to create add-ons that augment the known OAuth2 providers with custom data, which would allow an organization to publish a regular Thunderbird add-on that users can easily add to their installation via addons.thunderbird.net.

Developer toolbox seems to be failing to connect to localhost so I don't have any more network details to give.

Thanks for trying. I'm going to see if I can figure out how to reproduce the reauthentication issue with the account we have available to us next week.

I'm now having trouble signing in at all with today's daily. First it appears that something went wrong with the MFA configuration for my account. So I reset it and re-added SMS and MS Authenticator methods to my account. I'm able to login to My SIgn-Ins and check status. But TB fails to authenticate. I get the MS login screen for my password but after entering that it goes away and I get a failure method. It never prompts for MFA.

Console shows:
mailnews.oauth: Authorization error [invalid_resource]: AADSTS500011: The resource principal named https://outlook.office.com was not found in the tenant named bf4644cf-0c90-XXXXXX. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. Trace ID: 43b54645-f4c5-4eea-972f-a63203c80000 Correlation ID: a35dac63-9b62-4c7f-a08d-2a5b74a34a98 Timestamp: 2026-02-06 15:35:13Z See https://login.microsoftonline.us/error?code=500011. OAuth2.sys.mjs:293:18

That is our Tenant ID. No idea where "outlook.office.com" is coming from - the account still references outlook.office365.us. Maybe from the scopes field? The enterprise app still shows and my user is still assigned to it.

https://outlook.office.com is the prefix for the OAuth EWS scope URL (https://outlook.office.com/EWS.AccessAsUser.All), which as far as I'm aware should be the same across commercial Azure and GCC. Is the application ID you're using still allowed by your administrator?

Nothing really changed with the app registration that I created in GCC High and had been working for a bit. I have no idea where I should configure the "resource principal" "https://outlook.office.com" in my app registration.

I changed the OAuth Scopes to offline_access https://outlook.office365.us/EWS.AccessAsUser.All - that got me a different error:

mailnews.oauth: Scope "offline_access https://outlook.office365.us/EWS.AccessAsUser.All" was requested, but "https://outlook.office365.us/EWS.AccessAsUser.All" was granted. OAuth2.sys.mjs:386:17

So then I changed it to just https://outlook.office365.us/EWS.AccessAsUser.All and that seems to have worked. What's the point of offline_access?

offline_access allows you to access data without reauthenticating every request, which was the fix for the repeated authorization prompt issue. The weird thing about Office365 oauth is that we actually do get that permission even though we're told we didn't in the oauth response.

Others watching this issue: If you're still interested in trying this, please try and follow my instructions from comment 48 on this issue with the latest daily (151.0a1 >= 26 March 2026). We believe we've addressed the major issues surrounding this.

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

Attachment

General

Creator:
Created:
Updated:
Size: