Require Device Compliance for the non-primary user

As a lot of organizations are moving to the cloud, security becomes more and more important. While a most organizations have already enabled multifactor authentication, protecting your administrator accounts is of paramount importance.

Within Conditional Access, we can filter on the compliance state of a device. The compliance state is retrieved from the Intune managed device, where we can setup certain conditions to which a device needs to conform. These conditions can range from OS version, to Bitlocker up until making sure no active threats (alerts in MDE) are currently active on the device.

Using the compliance state is a great way of ensuring that users work from a “secure” device. Requiring a compliant device within Conditional Access works great when you are trying to login using the primary user of a device (which is configured in Microsoft Endpoint Manager).

When you try to log into Microsoft 365 using an account that is not the primary user of the device, your sign-in will be blocked.

My goal was to build a poor mans PAW, where we can ensure administrator accounts only log into administrator portals from compliant devices. My tests were being done with Microsoft Edge, but the experience will be the same for Chrome and Firefox.

Within the error we just saw, we are redirected to the Edge documentation that states a few steps that we need to take in order to use the compliant state within Microsoft Edge. They state that the user who is logging in should also be the one logged into the Edge profile.

But even if we do that, our sign-in will still fail. This is because we are signing in with a non-primary user. Within the sign-in logs, we’ll see that our compliance state isn’t being sent to Azure AD. Conditional Access evaluates that we are not signing-in from a compliant device and will block the sign-in.

The solution

While this is extremely annoying behavior, there is a solution for it which was recommended to me by Claus Jespersen on Twitter.

When you are creating a new profile in Edge, you need to sign-in into it. While you are signing-in, you will receive the prompt to choose if you want to sign into the current app only or you want to remember the account for all future apps. By default, I always select “No, sign in to this app only””, which will ensure the account is only used within Edge. The important step here is that you need to click OK, which will make the account available to all apps on your computer.

When you do this, the account will be added to your Windows machine and visible within the Settings – Accounts – Email & accounts pane.

By adding the account to Windows, it can retrieve the compliance state of the device and send that to Azure AD, even if the account being used isn’t the primary user of device.

Browser specific instructions

Edge

Besides adding the account to Windows, you need to ensure that the same account is also logged into the Edge profile.
Synchronization within the profile doesn’t need to be enabled, but you need to sign into the Edge profile with the same account as you are using in the Azure portal.

Firefox

Within Firefox version 91, we can also enable Windows SSO documented here. Enabling this setting and adding your non-primary account to Windows will also ensure that device compliance can be used for accounts other than the primary user of the device.

Chrome

Chrome is also supported in the same manner. Besides adding the account to Windows, you also need to install the Windows 10 accounts extension.

Note: Since version 111, the extension is not required anymore and the same behavior can be achieved by using the CloudAPAuthEnabled setting. In January 2024, this setting is not yet available in Intune ADMX templates.

Summary

This is a relatively short blog, but I wanted to share how we can use compliancy within Conditional Access to restrict browser access for non-primary use cases.

While every administrator should be restricted to a Priviliged Access Workstation (PAW) in an ideal world, this is too expensive and time consuming for a lot of customers. By using this solution, you can ensure administrators are logging in from “secure” devices, while keeping the TOC low.

It’s important to note that this solution is far from perfect. While you are restricting signins from your admins, an attacker will easily be able to pivot from the main account on the computer to the admin account saved on the device. The main advantage of this solution is that you limit the amount of devices that the account can be used on (personal devices are often not properly secured with an EDR and a security baseline), while the disadvantage is that an attacker can more easily pivot from the regular user account to the admin account (if the computer is breached).

When you are implementing such CA policies, it’s important to ensure a Break The Glass administrator is excluded from the policy. Ideally, you also provide a backup device to every IT admin in case their primary machine breaks (this is a great use case for AVD).

Final note: If you create a policy to require compliancy for browser access, remember that this is incompatible with an in-private window and not supported browsers. All my testing has been done using Microsoft Edge.