1697805 - o365 Oauth2 Authentication does not provide Device Information in (PRT) Token. Causes Thunderbird to be blocked by O365 Conditional Access policies. Extend auth to cover login.microsoftonline.com

Status: RESOLVED FIXED

(Thunderbird :: OS Integration, enhancement)

Description

[David]

Attachment: Thunderbird Conditional Access - no DeviceID.jpg

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.

Comment 1

[David]

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/

Comment 2

[Christoph Langer]

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

Comment 3

[Magnus Melin [:mkmelin]]

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.

Comment 4

[SebCav]

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

Comment 5

[Christoph Langer]

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.

Comment 6

[Magnus Melin [:mkmelin]]

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

Comment 7

[Christoph Langer]

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.

Comment 8

[matthias.baesken]

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?

Comment 9

[Magnus Melin [:mkmelin]]

(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)

Comment 10

[Christoph Langer]

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?

Comment 11

[Magnus Melin [:mkmelin]]

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

Comment 12

[Christoph Langer]

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

Comment 13

[Far Flung]

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

Comment 14

[Far Flung]

bug 1685414 ?

Comment 15

[Christoph Langer]

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

Comment 16

[Christoph Langer]

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.

Comment 17

[Magnus Melin [:mkmelin]]

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/

Comment 18

[Andrei Hajdukewycz [:sancus]]

(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.

Comment 19

[zusoimuhwigjizruba]

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

Comment 20

[Marcus Schmid]

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.

Comment 21

[Christoph Langer]

(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?

Comment 22

[Sean Burke [:leftmostcat]]

Attachment: Bug 1697805 - Use non-private browser for OAuth login. r=darktrojan

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/fd4deac7ec82
Use non-private browser for OAuth login. r=darktrojan