A first look at the new Conditional Access condition : Filter for devices



One of my favorite features within Microsoft 365 is Conditional Access. I haven’t blogged much about this yet, but it’s coming soon.

At Ignite, Microsoft announced the General Availability of a new condition: “filter for devices” which is actually the merger of “Device state (preview)” and “Filter for devices (preview)”.

I find this new set of conditions very interesting because it will bring much more granularity in managing access on a per endpoint and per population basis.

Of course, this is only a general context check. A user with knowledge of the verified criterias could very well circumvent the measure by renaming the workstation or by using this or that version of an OS. But one can also consider interesting quickwins like :

  • Restricting administrator access to names (without having to resort to MDM compliance)
  • Restriction of workstations from a population that cannot use strong authentication to certain types of workstations (whether or not they are included in a specific geographical area)
  • Restriction of workstations
  • Obsolete OS version blocking for unmanaged BYOD.

The different filters available are:

Attribute Description
deviceId GUID of the device
displayName Display name of the device
deviceOwnerhip “Personal” or “Company”
isCompliant “True” or “False”
manufacturer Manufacturer of the device
mdmAppId Application identifier used to register device into MDM
model Model of the device
operatingSystem Name of the operating system of the device
operatingSystemVersion Version of the operating system of the device
physicalIds Physical id of the device
profileType “RegisteredDevice”, “SecureVM”, “Printer”, “Shared”, “IoT”
systemLabels List of labels applied to the device by the system
trustType “AzureAD”, “ServerAD”, “Workplace”
extensionAttribute1-15 Custom attributes

The complete list of available operators and properties is described in the documentation.

Note 1: the “Filter for devices” conditions cannot be used with the preview “Device state” conditions

Note 2: The maximum length for the filter rule is 3072 characters.

Enough theory

In order to test this feature, very promising on paper, I created a policy blocking the access to my user “Elf” from my company workstation “PO44xxxx” on a web browser.

The policy is defined as follows:

After implementing the policy, I tried to connect via my favorite browser (Chrome).

First surprise: I passed through the conditional access policy without any problem.

In the logs, I see that my terminal is not analyzed (Device: Unknwown).

A closer reading of the documentation tells me that not all operators are supported for all device registration states.

I then decide to register my enterprise workstation within my test tenant (during sign-in in the Teams thick client) (sorry for the French screenshot 😉)

Within two minutes, my device appears in AAD for my user “Elf”.

In the logs, I see that the nature and information of my workstation are well known by Azure AD.

Second surprise: Except … my user can still access the different workloads via a Brower.

I then try to use Edge and there: bingo! Edge retrieves the information and the conditional access policy works as excepted.

My user sees this error message:

Sign-in logs show that the terminal has been recognized by Edge.

Wrap-up

We have seen in this article how to configure conditional access with the new condition “Filter for devices” (GA since early November).

I remember several things from it:

  • Not all clients are supported for conditional access policy evaluation. My various tests showed that at the moment Edge, PowerShell (with Azure AD module) were compatible while Safari, Chrome and Firefox were not supported.
  • As for other conditions, it may be interesting to think more in an exclusion logic than in an inclusion logic to force the application of the conditional access policy (e.g. block all devices, except those with a displayname starting with POxxxx)
  • “Filter for devices” is a interesting condition but the knowledge of it could enable a user to by-pass it.

Note for later, Continuous Access Evaluation does not support yet the “Filter for devices” condition. For example, a token could be extracted from on admin workstation and re-played on another device. Can’t wait to see what Microsoft will release to handle this kind of case (via token binding, Azure AD Identity Protection or CAE).