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

Steps to reproduce:

installing TB 102.7.2

Actual results:

After successful Microsoft multi-factor authentication, it complained about 'need admin approval' for 'Mozilla Thunderbird'.

Expected results:

I checked with our IT department. They mentioned that the permissions for TB are always the same as before (see attached image). Do they have to grant new permissions with this TB 102.7.2?

I have the same problem. since the update to 102.7, receiving emails via Microsoft accounts from the school no longer works.
Even a downgrade to 102.6 with the same profile does not bring success.

Interesting, I followed the link in https://blog.thunderbird.net/2023/01/important-message-for-microsoft-office-365-enterprise-users/ and downgraded to 102.6.1. It works.

The permissions are the same. BUT: It's now a * different client ID*, which your IT department needs to approve. See the blog post above.

Many thanks, wrote to the IT department already.

Same behavior here.
Our IT needed quite some time to believe it is the approval and not the application.

I have successfully consented the new Thunderbird application in Azure AD (9e5f94bc-e8a4-4e73-b8be-63364c29d753) and sign-in's and emails work as expected.
This was via Admin consent as will do not allow users to self consent.
However when consenting I received the following error:

Request Id: 9ff9e68b-7340-4a0c-b187-eccf98e63101
Correlation Id: 9c0f05b3-54a6-4ad5-a19c-6d0d3b9ae5ce
Timestamp: 2023-02-09T09:59:26Z
Message: AADSTS50011: The redirect URI 'https://entra.microsoft.com/TokenAuthorize' specified in the request does not match the redirect URIs configured for the application '9e5f94bc-e8a4-4e73-b8be-63364c29d753'. 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 new Thunderbird application did add successfully, it appears under Enterprise Applications with the expected permissions, all entries for this operation in the AAD Audit logs are successful, the existing "old" Thunderbird Enterprise Application (08162f7c-0fd2-4200-a84a-f25a4db0b584) still exists and old and new clients can successfully send and receive email.

So despite this consent error every thing works as expected, so is there a mistake in the new Thunderbird application configuration that is using an incorrect redirect URI?

I didn't get this error when registering the original "old" Thunderbird application.

(In reply to o.winterbone from comment #6)

I have successfully consented the new Thunderbird application in Azure AD (9e5f94bc-e8a4-4e73-b8be-63364c29d753) and sign-in's and emails work as expected.
This was via Admin consent as will do not allow users to self consent.
However when consenting I received the following error:

Request Id: 9ff9e68b-7340-4a0c-b187-eccf98e63101
Correlation Id: 9c0f05b3-54a6-4ad5-a19c-6d0d3b9ae5ce
Timestamp: 2023-02-09T09:59:26Z
Message: AADSTS50011: The redirect URI 'https://entra.microsoft.com/TokenAuthorize' specified in the request does not match the redirect URIs configured for the application '9e5f94bc-e8a4-4e73-b8be-63364c29d753'. 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 new Thunderbird application did add successfully, it appears under Enterprise Applications with the expected permissions, all entries for this operation in the AAD Audit logs are successful, the existing "old" Thunderbird Enterprise Application (08162f7c-0fd2-4200-a84a-f25a4db0b584) still exists and old and new clients can successfully send and receive email.

So despite this consent error every thing works as expected, so is there a mistake in the new Thunderbird application configuration that is using an incorrect redirect URI?

I didn't get this error when registering the original "old" Thunderbird application.

I tested the Admin consent with requests from both the 102.7.1 and 102.7.2 clients and received the same error for both.

I don't know where https://entra.microsoft.com/TokenAuthorize is coming from. It's not set by Thunderbird.
Perhaps you have some 3rd party authentication layer set up inbetween for your organization, and that's messing things up?

We don't have any 3rd party authentication layer, it's all direct to Azure AD, however I think I've worked out the cause.
Entra is the new Microsoft Identity and Access portal, it groups together all these related services including Azure AD and has the https://entra.microsoft.com/ URL.

I removed the new Thunderbird app and reconsented it via the old (non-Entra) Azure AD portal, can still access it via the original URL, and this registered successfully with no error - email works as expected.
Removed the new Thunderbird app and re-consented in Azure AD accessed via the new https://entra.microsoft.com/ URL and got the error again - the app did register correctly and email works as expected.

Our tenant has switched us to use this new https://entra.microsoft.com/ URL for Azure AD so anyone else who also defaults to accessing Azure AD via this may also encounter this error?

So a work around is to consent the app via the old (non-Entra) Azure AD portal.

Regardless of the error the new Thunderbird app does register successfully in Azure AD when using the Entra portal, so at worst this seems to just be a "cosmetic" error and doesn't affect any functionality.

(In reply to o.winterbone from comment #9)

...
So a work around is to consent the app via the old (non-Entra) Azure AD portal.

Regardless of the error the new Thunderbird app does register successfully in Azure AD when using the Entra portal, so at worst this seems to just be a "cosmetic" error and doesn't affect any functionality.

Edmond, with the above information, is your issue resolved?

(In reply to Wayne Mery (:wsmwk) from comment #10)

(In reply to o.winterbone from comment #9)

...
So a work around is to consent the app via the old (non-Entra) Azure AD portal.

Regardless of the error the new Thunderbird app does register successfully in Azure AD when using the Entra portal, so at worst this seems to just be a "cosmetic" error and doesn't affect any functionality.

Edmond, with the above information, is your issue resolved?

It's resolved in regard to it works fine and the https://entra.microsoft.com/ related error message appears to be a false positive.
I haven't re-tried this as I haven't needed to re-register the application as it's all working ok and I don't want to touch it due to it being in production use, so I can't say if the error is still received when registering it.

This has been resolved. I had to ask the administrator to approve again Thunderbird with its new client ID.