Earlier this month I wrote an article about using filtering in assignments for apps, compliance policies and configuration profiles in Microsoft Endpoint Manager. And now Microsoft has made available a preview of “Filters for devices” for use in your Azure AD Conditional Access policies.

Because this functionality is provided as a preview there is no service level agreement (SLA), and therefore Microsoft doesn’t recommend to implement its functionality for production workloads. Certain features might not be supported or might have constrained capabilities

Filters for devices are available as conditions which you can use when creating your Conditional Access policies, with this functionality you can include or exclude devices based on filters using a rule expression. Combining include and exclude is not supported.

Microsoft provides the following examples where filters might provide a solution in their documentation:

1. Give access to Azure Management for privileged users only, coming from privileged or secure admin workstations
2. Block access from devices running non supported Windows versions (like Windows 7, 8.1)
3. Do not require MFA for specific account (traditional AD service accounts) when used on specific devices, like Teams phones or Surface Hub devices

The documentation states that Device state (which allows you to exclude Compliant and/or Azure AD Hybrid joined devices) and Filters for devices cannot be used in one Conditional Access policy. You can use the Compliancy and Azure AD Hybrid joined status in the Filter for devices as well though using the trustType and/or isCompliant properties, so basically this means that the Device State condition might disappear in the future to be replaced by the Filters for devices functionality.

Under the Filters for devices the following attributes can be used:

deviceId, displayName, manufacurer, mdmAppId, model, operatingSystem, operatingSystemVersion, physicalIds, profileType, systemLabels, trustType

Besides these attributes also custom attributes which can be set on the device in the form of extensionAttribute can be used, for this 15 custom fields can be used.

Each attribute supports operators, like Equals or Contains. But not every operator is supported for each attribute. The following operators are available: Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In and NotIn

The following table, which I copied from the documentation give a very good idea of the available options for each attribute. The examples give an example of what’s possible for each attribute.

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”)
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)	(device.operatingSystemVersion -in [“10.0.18363”, “10.0.19041”, “10.0.19042”])
pyhsicalIds	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]”)
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 filters for devices condition in Conditional Access. Any string value can be used.	(device.extensionAttribute1 -eq ‘SAW’)

There are circumstances under which the Filter for devices conditions are applied or not applied depending on the Device registration state. So it’s important to realize that not everything that you build using the attributes and operators is supported. Microsoft describes these scenario in the following section of the documentation: Policy behavior with filters for devices.

It states for example that for unregistered devices, when using positive operators like Equals, StartsWith, EndsWith, Contains or In for any attribute the device filter is not applied, but when using the negative operators like NotEquals, NotStartsWith, NotEndsWith, NotContains or NotIn for any attribute the device filter gets applied.

Which while reading it from the documentation doesn’t make sense, let’s see if it makes more sense if we define an example. Let’s use the attribute manufacturer for that.

So based on the documentation the filter is not applied when we define that the device manufacturer should start with Microsoft, but the filter is applied when the device manufacturer property doesn’t start with Microsoft.

It can also mean though that the filter gets applied for negative operators on unregistered devices because the attribute cannot be determined. The means for example that in the case that the unregistered device is has the device manufacturer attribute of Microsoft and the operator is NotEquals Microsoft.. the filter will apply because the attribute “device manufacturer” cannot be detected on the unregistered device. If this is the case, this is a caveat that must really be made more clear.

I created an issue on the following GitHub page hoping that someone from Microsoft can give more insight about this: About Policy behavior with filters for devices · Issue #75955 · MicrosoftDocs/azure-docs (github.com). Once I know more I will update this article to reflect the exact working.

Conclusion

Filters for devices to be used in Conditions for Conditional Access policies are a welcome addition for situations where you would normally have to create all kinds of exception policies in order to accomplish the same result. Keep in mind though that this extra complexity, when implemented without any structure can result in unpredictable results allowing which could potentially lead to ways to circumvent Conditional Access policies. For example, if someone is able to read the Conditional Access policies, determine that in a certain scenario a Conditional Access policy doesn’t apply (for example when the machine name begins with ABC) that user might find a way to rename his/her machine with this naming convention allowing the user to bypass the Conditional Access policy.

If I’m really honest, I haven’t had any requirement yet in my current set of Conditional Access policies which require this filter functionality. But I might need some more time to think about these possibilities to see the added value.

References

Conditional Access: Conditions

Conditional Access: Filters for devices (preview)