Bugzilla

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=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

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