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

Steps to reproduce:

Connecting to O365 Exchange Online system with Thunderbird using Oauth2 Authentication the "DeviceID" information is not provided in the Primary Refresh Token (PRT). In O365 systems that utilize conditional access policies where only authorized devices are allowed to connect this information must be provided so the system connecting can be identified. If the information is not provided the client will be blocked.

To reproduce the issue connect to an o365 Exchange Online mailbox with Thunderbird where a conditional access policy is enabled. The client will be automatically blocked as no DeviceID information is provided to identify the client.

Actual results:

Thunderbird clients connecting in o365 environments where conditional access policies are enabled will be blocked. When attempting to connect to a mailbox the initial authentication process will complete successfully but the client will then be blocked and the user will then receive a popup advising:

This application contains sensitive information and can only be accessed from: Devices and Client applications that meet <organizations> management compliance policy.

Under the "more details" section of the client popup the DeviceID information will show as blank indicating this information was not provided by the Thunderbird client. Similarly the O365 signin logs will show this information was not provided by the client and as a result it was blocked.

Expected results:

If a DeviceID is correctly supplied and is found in the o365 Azure system meeting the conditional access requirements the system will be allowed to connect. Azure DeviceID information should be available from both Windows, MAC devices.

Additional details on the PRT and DeviceID requirement for O365 can be found here -> https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token

https://www.microsoft.com/en-us/microsoft-365/blog/2017/08/23/azure-ad-and-intune-now-support-macos-in-conditional-access/

As bug 1720341 seems to be fixed now in Firefox, will Thunderbird also be fixed?

See https://support.mozilla.org/en-US/kb/windows-sso
Should port bug 1695693, bug 1716360 and others in the area.

But it basically comes down to setting network.http.windows-sso.enabled to true, I believe. Does that work for you? You'll need Thunderbird 91 or above. The feature is Windows (10/11) only.

I'm not the reporter, but I have the same issue and network.http.windows-sso.enabled set to true does not change anything on Thunderbird 91.4.1

Yep, I can confirm. Just tried network.http.windows-sso.enabled=true on Thunderbird 91.4.1 and it doesn't work. I did that before, too.

When plaing with Firefox, I can see the effect of toggling network.http.windows-sso.enabled via using outlook web access. If it is true, I'm admitted. If it's false, I can't authenticate.

Would really be great if this change could be ported from Firefox to Thunderbird, too. I'm volunteering to test things if there's a beta...

PS: Our IT department threatens to enforce device authentication on Mac as well - but it has not been enabled yet. Not sure whether something is missing there, too. But first of all this is about windows.

Might be that the auth needs to be extended to also cover login.microsoftonline.com and not only live.com:
https://searchfox.org/mozilla-central/rev/fbf1e796ecead9484deced4d99f199f327ba25ab/netwerk/protocol/http/HttpWinUtils.cpp#65

This seems reasonable. login.microsoftonline.com seems to be what is used. When somebody can provide a build with this addition I can test it. Unfortunately it's not configureable dynamically.

Hello, would be great if you could add "login.microsoftonline.com" and provide a build for testing ( I have the same issue Christoph reported).
Or was that already done but the info was just not added to this bug?

(In reply to matthias.baesken from comment #8)

Hello, would be great if you could add "login.microsoftonline.com" and provide a build for testing ( I have the same issue Christoph reported).

I made such a build now. Get it here: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NGZu5Ks3T72n6WanExj6WQ/runs/0/artifacts/public/build/install/sea/target.installer.exe

(For other artifacts see https://treeherder.mozilla.org/jobs?repo=try-comm-central&selectedTaskRun=NGZu5Ks3T72n6WanExj6WQ.0)

Thanks a lot for this effort. I installed it and tried but it still shows the same behavior as before.

The version of Thunderbird Daily is: 102.0a1 (2022-05-13) (64-bit).

Is there any way I could collect some helpful traces/logs?

@Christoph - did you also set network.http.windows-sso.enabled to true? I had forgot to mention that.

Yes, it is set to true and the error reproduces. I can collect further logs if you need them...

Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=1685414?

bug 1685414 ?

Hi,

@sancus do you know whether this is a duplicate of bug 1685414? Or is this a different thing?

How can I test 1685414? (I have Thunderbird 102.6.1 installed...)

Thanks in advance!
Christoph

Update: I just tried with Thunderbird Beta right now. I see the screens as depicted in 1685414. I'm not an admin. Question: Will an administrator have to consent once for a particular Thunderbird client version and then it can be used on any client? Or does this consent have to be done for each and every client?

BTW: I'm posting here because 1685414 is closed and I can't add there.

Admin consent will be needed for the new client credentials. These will change (changed on beta) but are not tied to version.
See https://blog.thunderbird.net/2022/11/important-message-for-microsoft-office-365-enterprise-users/

(In reply to Christoph Langer from comment #16)

Update: I just tried with Thunderbird Beta right now. I see the screens as depicted in 1685414. I'm not an admin. Question: Will an administrator have to consent once for a particular Thunderbird client version and then it can be used on any client? Or does this consent have to be done for each and every client?

It has to be done once for the new clientid, Magnus explained this correctly! This change will be in 102.7.0 as well.

I'm not sure if this bug is also resolved by bug 1685414 but testing on 102.7.0 should determine that.

This is not fixed in 102.7.2. The device identifier is not available.

as setting network.http.windows-sso.enabled=true didn't help me either, I looked at the code, and it seems that Windows SSO information is only added in non-private windows [1] while the OAuth2 authorization is done in a private window [2].

So for testing purposes I modified the requestWindowFeatures in mailnews/base/src/OAuth2.jsm to read
"chrome,non-private,centerscreen,resizable,status,width=980,height=750" instead of
"chrome,private,centerscreen,width=980,height=750".

After that, I was able to authenticate with that modified Thunderbird against our company's Conditional Access-enabled Azure AD.

(In reply to Marcus Schmid from comment #20)

as setting network.http.windows-sso.enabled=true didn't help me either, I looked at the code, and it seems that Windows SSO information is only added in non-private windows [1] while the OAuth2 authorization is done in a private window [2].

So for testing purposes I modified the requestWindowFeatures in mailnews/base/src/OAuth2.jsm to read
"chrome,non-private,centerscreen,resizable,status,width=980,height=750" instead of
"chrome,private,centerscreen,width=980,height=750".

After that, I was able to authenticate with that modified Thunderbird against our company's Conditional Access-enabled Azure AD.

That sounds interesting. Could anybody build a Thunderbird Beta with this change for me to test?

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/fd4deac7ec82
Use non-private browser for OAuth login. r=darktrojan