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:
- Give access to Azure Management for privileged users only, coming from privileged or secure admin workstations
- Block access from devices running non supported Windows versions (like Windows 7, 8.1)
- 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||A valid operating system (like Windows, iOS, or Android)||(device.operatingSystem -eq “Windows”)|
|operatingSystemVersion||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||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
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.