During last week an customer had the need to make sure that all mobile devices that weren’t MDM enrolled into intune should get blocked for accessing Azure AD resources using mobile apps.
This due to start forcing specific users to start MDM enroll devices without having compliance policies at place within intune.
To achieve this, we will use an Conditional Access policy with the new Device Filtering condition.
About Device Filtering within Conditional Access
Since a couple of days back, Microsoft have launched the Device Filtering condition in general availability. This will enable us to target or exclude specific devices from an Conditional Access Policy.
Currently, there is only a subset of attributes that we can use to filter out devices within Conditional Access:
| Supported device attributes | Supported operators | Supported values | Example |
|---|---|---|---|
| deviceId | Equals, NotEquals, In, NotIn | A valid deviceId that is a GUID | (device.deviceid -eq “498c4de7-1aee-4ded-8d5d-000000000000”) |
| displayName | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.displayName -contains “ABC”) |
| deviceOwnership | Equals, NotEquals | Supported values are “Personal” for bring your own devices and “Company” for corprate owned devices | (device.deviceOwnership -eq “Company”) |
| isCompliant | Equals, NotEquals | Supported values are “True” for compliant devices and “False” for non compliant devices | (device.isCompliant -eq “True”) |
| manufacturer | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.manufacturer -startsWith “Microsoft”) |
| mdmAppId | Equals, NotEquals, In, NotIn | A valid MDM application ID | (device.mdmAppId -in [“0000000a-0000-0000-c000-000000000000”] |
| model | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | Any string | (device.model -notContains “Surface”) |
| operatingSystem | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system (like Windows, iOS, or Android) | (device.operatingSystem -eq “Windows”) |
| operatingSystemVersion | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | A valid operating system version (like 6.1 for Windows 7, 6.2 for Windows 8, or 10.0 for Windows 10 and Windows 11) | (device.operatingSystemVersion -in [“10.0.18363”, “10.0.19041”, “10.0.19042”, “10.0.22000”]) |
| physicalIds | Contains, NotContains | As an example all Windows Autopilot devices store ZTDId (a unique value assigned to all imported Windows Autopilot devices) in device physicalIds property. | (device.devicePhysicalIDs -contains “[ZTDId]:value”) |
| profileType | Equals, NotEquals | A valid profile type set for a device. Supported values are: RegisteredDevice (default), SecureVM (used for Windows VMs in Azure enabled with Azure AD sign in.), Printer (used for printers), Shared (used for shared devices), IoT (used for IoT devices) | (device.profileType -notIn [“Printer”, “Shared”, “IoT”] |
| systemLabels | Contains, NotContains | List of labels applied to the device by the system. Some of the supported values are: AzureResource (used for Windows VMs in Azure enabled with Azure AD sign in), M365Managed (used for devices managed using Microsoft Managed Desktop), MultiUser (used for shared devices) | (device.systemLabels -contains “M365Managed”) |
| trustType | Equals, NotEquals | A valid registered state for devices. Supported values are: AzureAD (used for Azure AD joined devices), ServerAD (used for Hybrid Azure AD joined devices), Workplace (used for Azure AD registered devices) | (device.trustType -notIn ‘ServerAD, Workplace’) |
| extensionAttribute1-15 | Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotIn | extensionAttributes1-15 are attributes that customers can use for device objects. Customers can update any of the extensionAttributes1 through 15 with custom values and use them in the filter for devices condition in Conditional Access. Any string value can be used. | (device.extensionAttribute1 -eq ‘SAW’) |
Device Filtering can be used for several different scenarios, such as:
- Target specific policies to Privileged Access Workstation (PAW) devices
- Exclude devices like Teams phones or Surface Hub devices from CA policies
- Block specific devices from accessing Azure AD resources when running an unsupported operating system
Configure Conditional Access Policy
Let’s configure the Conditional Access policy that will solve the customers issue, where we simply need to block access from all mobile devices using mobile apps against Azure AD resources.
Please note that we will still allow the devices to reach Azure AD resources through browser sessions.
Cloud Apps
Include: All Cloud Apps
Exclude: Microsoft Intune Enrollment
Exclude: Microsoft Intune
Conditions
Device Platforms:
Include: Android
Include: iOS
Include: Windows Phone
Filter for Devices:
Devices matching the rule: Exclude filtered devices from policy
device.mdmAppId – eq “0000000a-0000-0000-c000-000000000000” – or device.mdmAppId – eq “00000002-0000-0000-c000-000000000000”
Client Apps
Include: Mobile apps and desktop clients
Access Controls
Block Access
Summary
This conditional policy will block all mobile devices using Android/iOS/Windows Phone that aren’t MDM enrolled within intune from accessing Azure AD resources, but will still allow access through browser sessions.
It’s of course important that the organization have separate Conditional Access policies to secure browser sessions and device registrations as well.
Please note that if the device have been enrolled within intune in the past, the device might have the mdmAppId attribute populated, and will not be hit by the Conditional Access Policy.
Kudos to Tom Aafloen and Joakim Högström for contributing to the idea of filtering on the mdmAppId attribute.
Microsoft 365 Security blog by Pontus Själander 
16 replies on “Block Access for all non-Intune MDM enrolled mobile devices in Conditional Access”
I enjoy, result in I found just what I was taking a
look for. You have ended my four day long hunt! God Bless you man.
Have a great day. Bye
LikeLiked by 1 person
I’m so glad to hear that you found what you were looking for! Your kind words mean a lot, and I’m thrilled I could assist you in your search. If you ever have more questions or need further assistance in the future, don’t hesitate to reach out. Wishing you a fantastic day ahead! Take care!
LikeLike
Hi Pontus
Good Article.
Sometimes users cache credentials locally (first time login) when launching AVDs using RDP. How to block this action of storing credentials in the windows registry from unmanaged devices (or make it expire during subsequent logins)?
LikeLike
Great article. I am experiencing some of these issues as well..
LikeLiked by 1 person
I’m glad to hear you found the article helpful! It’s not uncommon to encounter these issues, but I’m here to help. If you have any specific questions or need further advice on how to address them, feel free to let me know
LikeLike
This was an excellent article and super helpful in a recent implementation I was working with a customer on. Can’t thank you enough!
LikeLiked by 1 person
This was an excellent article and super helpful in a recent implementation I was working with a customer on. Can’t thank you enough!
LikeLiked by 1 person
Thank you so much for your kind words! I’m thrilled to hear that the article was helpful for your recent implementation. If you have any more questions or need further assistance, please don’t hesitate to reach out. Happy to help anytime!
LikeLike
Looking for conditional access policy which users are there in Microsoft AD or AAD but devices are enrolled in other MDM provider. End user should access Office 365 apps on his work profiles only.
LikeLiked by 1 person
Thank you for reaching out! I’d be happy to assist you further, but could you please provide a bit more detail about your question? Specifically, could you elaborate on the specific challenges you’re facing with your current setup, and what access demands or requirements you have in mind? This additional information will help me tailor my response to your specific situation. Looking forward to hearing more from you!
LikeLike
Could you provide the process for restricting browser access on all non-Intune personal devices? Each time I have tried this with conditional access, it restricts my enrolled devices as well.
LikeLike
It appears that blocking or granting access to cell phone apps would also block or grant access to desktop apps. How is it possible to apply a CA to ensure cell phones have Intune enrolled (and the device reports as compliant) without it locking them out of their desktop apps, such as Outlook and Teams?
LikeLike
Hi,
You need to separate the policies on device platform to achive this. Hit me up with your setup and I can get back to you with some feedback
LikeLike
Great post.
Do you know how to achieve the goal to block private devices AND allow private devices to be registered?
The usecase is that we want wo block not-managed devices (private devices) AND allow them to use the Authenticator App for passwordless login.
Using passwordless need the devices to be registered but not be managed. The block rule for unmanaged devices locks the users out from registering their private devices.
LikeLike
this is exactly the scenario we have, very keen to learn of you get a result with this
LikeLike
Been puzzling over this for a while.
I can’t seem to workout how I also add the authenticator app to the excluded apps. As its a BYOD scenario the choice to enrol is the persons individual choice – if they dont want to fine. No access to company resources on the device.
What I dont want to do though is stop the users from using the authenticator for MFA on the device. Does anyone have a suggestion?
LikeLike