Conditional Access public preview functionality reviewed (22H2) – Part 2: Conditional Access filters for Apps and Workload Identities

In the last couple of months, Microsoft released new functionality for Azure AD Conditional Access. All of this functionality is still in public preview, so please read the following article on what to expect from Preview functionality: Preview Terms Of Use | Microsoft Azure

In these series of articles I will go through the following new functionality:

• Part 1: Authentication Strength
• Part 2: Conditional Access filters for Apps and Workload Identities (this article)
• Part 3: Granular control for external user types

On October 26th, Alex Weinert the Director of Identity Security at Microsoft announced the public preview of Conditional Access filters for apps. With filters for apps, we can use custom security attributes to “tag” Enterprise Applications and Service Principals and use that tagging when targeting your workload identities and Apps in Conditional Access.

Conditional Access filters for Apps and Workload Identities use cases

I think the best feature of the filtering for apps and workload identities is that it allows you to configure your Conditional Access policy once, and adapt it based on the filtering being used. By doing this you prevent mistakes that could happen when modifying the Conditional Access policy. Another advantage is that you can delegate the “tagging” to another group of administrative users, without the need for those users to be able to create of modify Conditional Access policies.

Please note that Microsoft makes the following comment about scoping Conditional Access policies to service principals:  In public preview, you can scope Conditional Access policies to service principals in Azure AD with an Azure Active Directory Premium P2 edition active in your tenant. After general availability, additional licenses might be required.

Using this filter functionality we can implement some new use cases like:

• Create a specific Conditional Access policy for all Apps which are tagged with a tag UsedByDepartment and value Finance
• Create a specific Conditional Access policy only allowing “tagged” workload identities to be used from trusted locations
• Create a specific Conditional Access policy, which blocks medium and high “Service Principal risk” for “tagged” workload identities

Rights needed for the Custom Security Attributes

Before you can define, or assign Security Attributes, you must be authorized via an Azure AD role. For this the following Azure AD roles are available:

• Attribute Definition Administrator
• Attribute Definition Reader
• Attribute Assignment Administrator
• Attribute Assignment Reader

What’s interesting here is that the rights of these roles are not available to the Global Administrator role.

The Attribute Definition Administrator can create definitions of the attributes, which can then be used by an Attribute Assignment Administrator and put them on Apps, Workload Identities, but also to use these definitions in an Conditional Access policy. If you have the rights to create/modify Conditional Access policy but are not a Attribute Assignment Administrator you cannot assign the filtering. I also did some further testing, and could assign security attributes in a Conditional Access policy using the Attribute Definition Reader role, but for example not assign any attributes to an account in Azure AD. If the Attribute Definition role is not available for your account, you won’t be able to assign at all.

Creating custom Security Attributes

You can create custom security attributes, by going to the “Custom security attributes (Preview)” section in the Azure AD Admin portal. Creating custom security attributes consists of the following steps:

1. Create attribute set
2. Specify attribute

Create Attribute set

The first thing you must do, is create an Attribute Set. An attribute set is a collection of related attributes. You can create a new attribute set, by clicking on the “+ Add attribute set”, after which you must define an Attribute set name, optionally provide a description and specify the maximum number of attributes.

Specify Attribute

Within an Attribute Set you can specify custom security attributes, which is a key-value pair. You are required to specify the name of the Attribute, it’s data type (String, Boolean or Integer), whether multiple values can be assigned, and whether you only allow predefined values to be assigned. Last but not least, you can create predefined values, so that only those values can be used while assigning the attributes.

Eventually you can create multiple attributes, with predefined values within an Attribute set

Assigning Security Attributes

Assigning the security attributes must be performed on the resource (the App or the workload identity) and you should reference the security attribute in a filter in your Conditional Access policy.

• Assigning security attributes to an Enterprise Application
• Specify security attributes in a filter for Apps in your Conditional Access policy
• Specify security attributes in a filter for workload identities in your Conditional Access policy

Assigning security attributes to an Enterprise Application

An Attribute Assignment Administrator can assign the predefined security attributes as part of an attribute set to Enterprise Applications. In the example below, we tag the “Keeper Password Manager & Digital Vault” Enterprise Application with the following attributes:

UsedBydepartment: IT

UsageOnNonCompliantDevices: Not allowed

Keep in mind that only a Conditional Access policy can only be applied to single tenant service principals that have been registered in your tenant. Third party SaaS, multi-tenanted apps and Managed Identities are out of scope but can be provisioned with security attributes.

A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant application also has a service principal created in each tenant where a user from that tenant has consented to its use.

Specify security attributes in a filter for Apps in your Conditional Access policy

Using this filter, we can create a Conditional Access policy which only allows Compliant devices to access the app.

Specify security attributes in a filter for workload identities in your Conditional Access policy

Policy can be applied to single tenant service principals that have been registered in your tenant. Third party SaaS and multi-tenanted apps are out of scope. Managed identities are not covered by policy.

Using this filter will allow us to create a Condition which will block access to the Service Principal, except from a trusted location.

Conditional Access filters for Apps and Workload Identities Conclusion

The filters for Apps and Workload Identities functionality can really help to further mature your Conditional Access implementation. By delegating control to the Cloud Application administrators to use the predefined Security Attributes to tag their Enterprise Applications and Service Principals, we have the option to define generic Conditional Access policies for the different use cases. (For example, only allow Finance applications on Compliant devices)

With options comes more complexity though, be very careful with that. Make sure that you have a solid and stable Conditional Policy framework in place before starting with this kind of scenarios.