@MrMellie can you reproduce this issue using private browsing instead of a container?

Hi, I haven't tried Private Browsing, but from memory, any private session doesn't send device ID either.

Edit: just tried it and get the same error as container tabs.

You can't get there from here
This application contains sensitive information and can only be accessed from:

Devices or client applications that meet management compliance policy.

Hi, I started to face the same issue today when up to today it was fine, I have tried on an anonymous tab and it is the same error as with the containers.

Thanks. Can you tell me how I can reproduce the issue?

Hi Balkuf, the steps to reproduce are in the initial post under Steps To Reproduce :)

If you haven't got access to an Azure tenant with conditional access policies that require a device ID, you might struggle though.

Right so, lets say you login to portal.azure.com, that works fine, as soon as you open a incognito or a container, when you try to open it said that your sign-in was successful but it only managed devices are allowed, as per that, if you opened the
about:preferences#privacy
with the same container as the one you cant login , you would find the setting about allowing Windows sign-on for microsoft, grey'd out, (might be cause of my company policy) as seen bellow

Funnily enough the very next day after I replied, it was fixed, i guess it was something mozilla // microsoft messed up, (not their first rodeo.) so now it just works..

It's still not working for me. I think the problem maybe linked to, but not solved by the SSO setting. Device compliance is not the same as SSO.

I have the SSO option turned OFF. This was the whole point of me using FF and containers, I do not want a list of 14 accounts and the local device account to pop up every time I'm opening a new tab in one of half a dozen Azure tenants I'm managing, as other lesser browsers do.
With FF, containers, one set per Tenant I manage, it remembers which account I'm using for that tenant and only signs in with that.

Has anyone had a chance to look at this?
thanks

This is now even more broken after the last update to FF, non-container tabs no longer work. I think this is a core FF problem rather than the extension itself.

What makes you think this is a FF problem? This works for me in a non-container tab, any container tabs are not sending the device information however...

Using Firefox on MacOS Sequoia v15.1.1 with M3 processor. Firefox Multi-Account Containers v8.2.0. PlatformSSO enabled. SSO works fine in a non-container tab. Any tabs from the addon is failing auth due to missing device id.

Sample error from an auth attempt to Microsoft Security Center (removed identifying info):
Error Code: 530001
Request Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Correlation Id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Timestamp: 2024-12-10T21:26:59.979Z
App name: Microsoft 365 Security and Compliance Center
App id: 80ccca67-54bd-44ab-8625-4b79c4dc7775
IP address: 999.999.999.999
Device identifier: Not available
Device platform: macOS
Device state: Unregistered

What makes you think this is a FF problem? This works for me in a non-container tab, any container tabs are not sending the device information however...

It was working before the last update and then afterwards, it didn't. What version are you on? I know our CAP has not changed, it would be my team making the changes.

Firefox 133.0 (aarch64)

What makes you think this is a FF problem? This works for me in a non-container tab, any container tabs are not sending the device information however...

Using Firefox on MacOS Sequoia v15.1.1 with M3 processor. Firefox Multi-Account Containers v8.2.0. PlatformSSO enabled. SSO works fine in a non-container tab. Any tabs from the addon is failing auth due to missing device id.

Now try and turn Single Sign On in the browser Off. The device ID should still be sent, but it isn't. I am not logging in to Azure with the same account I sign in to my device with (my regular user account)- I'm using my cloud admin account credential that is not used to sign in to my device.

If I understand the add-in Multi-Account Container correctly, it just surfaces underlying FF functionality with a GUI to manage your containers. Since raising the ticket 8 weeks ago, I've found you can do the same thing in a less user friendly way using the About:Config page with no add-in installed.

I'm using multiple accounts as well, the reasoning behind using containers is to have different accounts per container in my scenario (admin account being one of them). I've tested both with network.http.microsoft-entra-sso.enabled true and false. Even tried the option for private browsing, but this errors too.

I'm thinking, since the id is sent correctly from a non-container tab, that things are working in FF (without fully knowing the backend implementation). However, as soon you attempt any auth with a container-tab, the device ID is not send.

Yes, that is pretty much my scenario too. I have 8 (eight!) tenants to administer and I am using containers to isolate the admin account for each tenant. I also have test accounts that I use in containers (hence needing the device ID sent in a container tab and raising this ticket). My normal user account (email etc) is used in Edge to completely isolate admin and standard accounts. I have the SSO setting turned on in Edge so it uses the account registered in Windows.

The non-container tab is used for the admin account on my primary tenant in which the device is hybrid joined. I will often have multiple tabs open per tenant, If I open a new tab in a container, it remembers who I'm logged in as and just opens the portal page with no grief. It uses to do this for my non-container tab too until the 133 update.

Now, in order for my main admin account to log in successfully, I have to enable Windows SSO in Firefox - this means I have to register my admin account in Windows and every time I open a new tab I get a pop-up asking which account I want to use and I have to make sure to to select the right one. It's "only 1 click" but it slows down opening new tabs and over the course of the day builds up to a lot of inconvenience and potential for selecting the wrong account.

It also has the knock on effect of breaking Edge with the same problem, a pop-up to select the correct account for each new tab, even my corporate VPN does not open without prompting for an account now (it should just connect on boot up).

I'm thinking, since the id is sent correctly from a non-container tab, that things are working in FF (without fully knowing the backend implementation).

My thinking is that sending the device ID has been (incorrectly) baked into the Windows SSO setting. I think I recall seeing you can turn SSO on in each container tab, something you could test maybe? I just don't want Windows SSO turned on at all in FF but I do need the device ID to be sent so I can authenticate (enter my password and MFA per tenant) and get through Conditional Access.

https://github.com/mozilla/multi-account-containers/wiki/Frequently-asked-questions#enable-windows-sso-in-a-specific-container

@mkaply I remember you implemented something around Windows SSO and containers. Would you have any idea if this is related?

My issue is on Mac with Platform SSO, but I might need to create an issue to not hijack this one? :)

@molldk Klaus, I think your issue is common to both platforms (Device ID not being sent with container tabs), that is why I originally raised the ticket. Since then, functionaility of non-container tabs look to have diverged between the platforms with v133.

The weird thing for me is that this seemed to work before we enabled PlatformSSO. But I can't rule out that my account was simply excluded from the compliant device check before. Nevertheless, the device id is not sent with requests from anywhere but a non-container tab as far as I can tell. If someone could point me to the source file, I could attempt to take a look, as I'm not really sure where to look.

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#445-466
By reading this code, Firefox requires special prefs to enable Windows SSO for containers: "network.http.windows-sso.container-enabled." + containerID.

I think the right steps to fix this issue are the following:

• extend the ContextualIdentity API to support Windows SSO per containers
• implement the support for Window SSO per container in this add-on.

Temporary solution: set the pref manually in about:config. Please confirm that the issue is fixed by setting those boolean prefs to true.

Negative @bakulf, the device ID should be sent independant of the SSO flag setting on both non-container tabs and container tabs for a regular browser session. I need the device ID sent with Windows SSO turned Off. I sign in manually with my Admin and Test accounts in the containers but am still subject to Conditional Access Policies in Azure/Entra.

I beleive other people have requested Window/Platform SSO for containers (see my previous link) which your solution would solve, but that is not the requirement of the Issue I have rasied.

Agree the device id is more part of Entra Conditional Access, and not SSO only. You can still require a compliant device without full SSO implementation.

I see no reason why device-id isn't sent in all tabs, container based or not. SSO is independent from conditional access in this aspect.

I see no reason why device-id isn't sent in all tabs, container based or not. SSO is independent from conditional access in this aspect.

I'll be honest, I don't fully understand this (and Microsoft didn't bring it up when we did the implementation).

What sites would we send it to? We wouldn't send it to every site on the internet, that would be a privacy issue.

In my instance, it needs to go across in the saml token when signing into Microsoft sites (dozens of different portals) using my corporate IDs (so not consumer sites like Hotmail) -.e.g https://portal.azure.com, https://intune.microsoft.com, https://admin.microsoft.com etc etc

So if I'm understanding, you want to be able to login manually using an account other than what is built in to your machine, but then still send the device ID so that conditional access (device specific access) works?

I'm assuming it is part of the protocol where the device certificate is used in auth as well. But it is really hard to find any guidance from Microsoft on how this should actually be implemented in applications like a browser. Most documentation you can find is either how to setup Conditional Access for validating devices, OR regular authentication flows, that doesn't seem to mention device compliance at all (probably checked in backend by Entra based on deviceid, certificate and Intune status).

Since this work in regular non-container tabs, maybe code from FF can provide a hint on how to replicate same behavior with containers?

So checking request header from a non-container tab and a container tab, I see more headers for the non-container tab. Specifically:

• x-ms-RefreshTokenCredential1
• x-ms-DeviceCredential
• x-ms-RefreshTokenCredential
• TE: trailers

The first 3 looks like generic Bearer tokens, so not sure if its because my browser is already logged on or something in relation to device compliance/client certs

Auth endpoint in these cases are:
https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize

Tested logging in to Azure Portal with same account

Here's what we do on Windows (It's prettty simplistic)

https://searchfox.org/mozilla-central/source/netwerk/protocol/http/HttpWinUtils.cpp#71

We ask the OS for info for a given URL (getCookieInfo) and then append the appropriate headers to the request if they begin with "x-ms-"

I've asked Msft for additional guidance on what to do here. (They told us how to implement)

So if I'm understanding, you want to be able to login manually using an account other than what is built in to your machine, but then still send the device ID so that conditional access (device specific access) works?

Hi Michael, yes that is correct.

Have you had any luck with Msft @mkaply ? (or got a "it's by design" type reply)

I'm also curious what changed between v130 and v133, as non-container tabs, at least, worked in v130.

Microsoft said, and I quote:

"We don't want to support this pattern."

Nothing related to Windows SSO changed between 130 and 133 (that I know of)

If it definitely used to work, you can use mozregression:

https://mozilla.github.io/mozregression/

and we can figure out what happened.

"We don't want to support this pattern."

What on earth does that mean? We don't understand why an admin would want to sign on without SSO so we CBA to look at it? Typical MS fob off.

I'll have a go with mozregression tomorrow and let you know the results.