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.

Filters for devices (Preview)

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

Create include or exclude filter

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 attributesSupported operatorsSupported valuesExample
deviceIdEquals, NotEquals, In, NotInA valid deviceId that is a GUID(device.deviceid -eq “498c4de7-1aee-4ded-8d5d-000000000000”)
displayNameEquals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInAny string(device.displayName -contains “ABC”)
manufacturerEquals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInAny string(device.manufacturer -startsWith “Microsoft”)
mdmAppIdEquals, NotEquals, In, NotInA valid MDM application ID(device.mdmAppId -in [“0000000a-0000-0000-c000-000000000000”]
modelEquals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInAny string(device.model -notContains “Surface”)
operatingSystemEquals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInA valid operating system (like Windows, iOS, or Android)(device.operatingSystem -eq “Windows”)
operatingSystemVersionEquals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInA 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”])
pyhsicalIdsContains, NotContainsAs 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]”)
profileTypeEquals, NotEqualsA 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”]
systemLabelsContains, NotContainsList 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”)
trustTypeEquals, NotEqualsA 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-15Equals, NotEquals, StartsWith, NotStartsWith, EndsWith, NotEndsWith, Contains, NotContains, In, NotInextensionAttributes1-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.

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.

Conditional Access: Conditions

Conditional Access: Filters for devices (preview)

Previous articleA bit of AI – Episode 12
Next articlePresenter Mode (standout) is in Public Preview!
avatar
I started my career in 1995 as a System Engineer in the broadcast industry, building and maintaining video editing suites and television studio's and later specializing in Telecine equipment. In 1998 I switched to a first line support function within the Information Technlogy on the dealing room of a large bank, working my way up to a 3rd line support engineer. From this position i started to work on projects, which eventually resulted in projects where I worked across the border. In this period I implemented and designed several deployment solutions for mass rollout of workstations, laptops and servers. Since 2009 I switched to a consultancy function mainly focusing on but not limited to System Center design and implementation projects, besides that I became a Microsoft Certified Trainer (MCT) and currently teach System Center Related Classes (SCCM, SCOM and SCSM). In Januari 2010 I received the Microsoft MVP award with the expertise Setup & Deployment which was extended in 2011 and 2012. In 2013 and 2014 I was awarded the VMware vExpert award. In october 2014 I received the Microsoft MVP award with the expertise System Center Cloud and Datacenter Management (SCCDM).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.