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.
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.
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.
Device state (preview)
This preview feature is being deprecated. Customers should use Filter for devices condition in Conditional Access to satisfy scenarios, previously achieved using device state (preview) condition.
device state option not SEEN ON CONDITIONAL ACCESS POLICY..PLEASE WHY IS THAT
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.
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?
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.
You’re update about the settings not working doesn’t have a date stamp, that might be useful if your blog is found in e.g. 2 years 🙂
Ps. I think you might find this an interesting article on conditional access: https://www.christiaanbrinkhoff.com/2018/08/31/deliver-citrix-and-office-365-applications-secure-by-using-conditional-access-in-workspace-365/
Yes, we see the device state preview feature.
Interesting. It certainly seems to coincide with the CA policies breaking for multiple tenants here, but I’ll keep testing it out. Maybe something else was happening as well.
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.
Do you see the new device state preview feature in your tenant as well?