I’ve previously written about how to use Azure AD conditional access to enforce multi-factor authentication for unmanaged devices when connecting to Office 365 services.

Some recent commenters reported that the policy demonstrated in the tutorial wasn’t working for them. I spent some time in my test tenant trying to reproduce the problem, and found that mine had also stopped working.

To summarize how the conditional access policy should work, the outcome should be:

  • A user logging in from an unmanaged device should be prompted for multi-factor authentication
  • A user logging in from a managed device should not be prompted for multi-factor authentication

To achieve that outcome, the conditional access policy was configured to grant access if the user passed MFA, OR the device is hybrid Azure AD joined, OR the device is marked compliant. The “OR” condition is defined by the “Require one of the selected controls” option.

New Azure Active Directory Conditional Access Device Conditions for Device State

As I explain in the article, this is a different approach than simply requiring MFA for external users, and bypassing MFA for internal/trusted IP ranges. The rationale is that network locations are a poor signal of trust, whereas a managed device can be considered more trustworthy on the basis that you can require it to meet your device compliance policies, have up to date security software installed, and so on.

As a side note to this, a recent addition to Intune is the ability to integrate with Windows Defender ATP and take into account the device security state (e.g. whether suspicious behaviour has been detected on the device) when determining device compliance.

Anyway, the problem reported by the commenters also started to impact me personally in my production tenant, with my iPhone prompting for MFA in Outlook any time I’m outside the office. Super annoying, and not what I want for my user experience.

Looking further into the issue, I stumbled across a new conditional access policy condition for “Device state”. This feature is currently in preview.

New Azure Active Directory Conditional Access Device Conditions for Device State

Per the official docs:

The device state condition allows Hybrid Azure AD joined and devices marked as compliant to be excluded from a conditional access policy. This is useful when a policy should only apply to unmanaged device to provide additional session security. For example, only enforce the Microsoft Cloud App Security session control when a device is unmanaged.

According to this commit, the documentation was updated on April 27th, which is a few days before people started leaving comments on my previous blog post saying that the tutorial no longer works as intended. A few weeks prior to that I was able to run through that exact scenario for a demo in my Office 365 security course and it was working fine.

I haven’t seen any announcements about the new control rolling out, but I’m still looking for those. Either way, after updating my conditional access policy to use the new preview control to exclude my trusted devices from MFA, everything is working again as intended in both my test tenant and my production tenant.

Update: I’ve since rolled back to my original policy configuration, and it’s now working as before. I’m not sure why it was failing for a few days there, possibly some other issue that happened to impact both tenants (and the other commenters who were having problems). I will keep an eye on things and update this post again if I see more issues.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. NMESOMA

    device state option not SEEN ON CONDITIONAL ACCESS POLICY..PLEASE WHY IS THAT

  2. Sri Satheeskumar

    Hi Paul
    I am using device state in my CA, but the results are inconsistent. Some hybrid Azure AD joined devises work fine and others not. My CA policy checks for devise state to enforce MFA on a user. Dsregcmd /Status shows no issues.
    Any clues?

  3. Dan Swit

    Do you consider conditional access based on serial number of the device as Multifactor authentication, if it is used as the second condition, after user name and password, and you do not authenticate to the second challenge of device serial number?

  4. MerimM

    Hello Paul, Always great to visit your site and find some terrific content.

    Just to add my 2 cents and personal experience related to conditional access. Over the past several months I have noticed that occasionally a mobile device will get a seemingly “new” IPv6 issued from the phone carrier and it “will” cause false positives, first hand experience here. When that happens, the session is blocked for the user and email on phone does not work, obviously, this depends on how you have the CA setup either to block or to prompt for MFA. Anyway, when the “new” IPv6 issued to the device the location can not be pinpointed and therefor the access is blocked, in our case. So this may be something to consider in your troubleshooting steps. I hope it helps.

  5. Dinko Fabricni

    Yes, we see the device state preview feature.

  6. Dinko Fabricni

    Hello,

    In my company we use the same access control as you did in the referenced article:
    – Require multi-factor authentication
    – Require device to be marked as compliant
    – Require Hybrid Azure AD joined device

    + Require one of the selected controls

    However, we don’t use Locations condition as you are and we don’t experience the issue reported. There is no need to configure Device state condition to exclude Compliant/Hybrid Azure AD joined devices.

    With regards,
    Dinko

Leave a Reply