Container tabs not sending Device ID for conditional access compliance.

[MrMellie]

Before submitting a bug report

• I updated to the latest version of Multi-Account Container and tested if I can reproduce the issue
• I searched for existing reports to see if it hasn't already been reported

Step to reproduce

1. Open Azure Portal (https://portal.azure.com) in a container tab to a tenant that uses Conditional Access Polices that require a compliant device (your device must be registered on said tenant, as mine is).
2. Enter creds
3. Get error message that device is not compliant.

Actual behavior

After trying to sign in, Entra/Azures gives an error message indicating my device is not compliant.

Expected behavior

It should log in just like a non-container tab.

Additional informations

The container tabs are not sending the device ID as a signal to enable logins to pass CAP where trusted devices are a requirement. Regulat tabs within Firefox are sending the device ID okay. This is not to be confused as a SSO issue - Windows SSO is turned OFF and not required for normal or container tabs in this scenario.

Provide a copy of Troubleshooting Information page (optional)

Sign in log details:
Authentication requirement
Multifactor authentication
Status
Failure
Continuous access evaluation
No
Sign-in error code
53000
Failure reason
Device is not in required device state: {state}. Conditional Access policy requires a compliant device, and the device is not compliant. The user must enroll their device with an approved MDM provider like Intune.
Additional Details
Your administrator might have configured a conditional access policy that allows access to your organization's resources only from compliant devices. To be compliant, your device must be either joined to your on-premises Active Directory or joined to your Azure Active Directory.

Device ID
Browser
Firefox 130.0
Operating System
Windows10
Compliant
No
No response

[bakulf]

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

[MrMellie]

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.

[VoskosSas]

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.

[bakulf]

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

[MrMellie]

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.

[VoskosSas]

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

[MrMellie]

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.