Disclaimer: the following configurations require Microsoft Entra Workload Identities Premium licence (link)
Note: This post is not strictly related to fighting client secret usage for apps. However, it may provide a basis for considering the purchase of Microsoft Entra Workload Identities Premium licence for at least those apps that use client secret.
In my previous posts I wrote about reviewing client secret usage (part1) and limiting app password lifetime (part2). This time I will protect one of my applications with Conditional Access policy using a location condition.
The process is very straightforward: create a CA policy, choose the service principal(s) to protect, select All cloud apps as Target resources, set up the location condition and the access controls. In my case it was simply blocking access from anywhere but the ‘Office’
The result when trying to get a token outside the office:
Get-MsalToken : AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.
Looking at the Sign-in logs:
Okay, this is cool, but it is nothing more than implementing what is already documented by Microsoft (here). What I thought might be useful to share is to combine Workload identities conditional access with custom security attributes (preview feature at the time of writing).
Workload identity Conditional Access with Custom security attributes
Application custom security attributes (link) is an awesome feature and is a great way to “group” applications/service principals. In this demo, I will mark some service principals that are supposed to be used only in the office and nowhere else – and use this property as a filter for the CA policy.
To add an attribute set you need to be assigned the Attribute Definition Administrator role (Global Admins do not have this permission by default, but they can assign it to themselves). Unfortunately Integer or Boolean attributes can’t be used for filtering*:
Using custom security attributes you can use the rule builder or rule syntax text box to create or edit the filter rules. In the preview, only attributes of type String are supported. Attributes of type Integer or Boolean will not be shown.
*My first idea was to mark applications with something like ‘CanOnlySignInFromOffice’ boolean attribute, but this restriction pushed me to a more sophisticated approach.
To overcome this restriction, I will create an attribute which will have a predefined set of sign-in-permitted locations (Office1, Office2… sorry for not being too creative here 🙂 ):
First, I created the ‘ProtectedWorkloadIdentites’ attribute set:
Next, click on Add attribute:
Then create the attribute (SignInRestrictedToNamedLocation) with String type, allowing only predefined values (hint: if value names are the same as the Named Locations it will be easier to administer):
Next step is to assign the attribute to the service principal that should be restricted: Enterprise applications -> [app to be restricted] -> Custom security attributes
Final step is the Conditional Access policy – this time using the filter instead of directly choosing the identites:
Target resources remains “All cloud apps”:
Location condition is set to Any location with Office1 excluded:
The action is Block access of course.
Let’s look at the results:
I’m sure there are more complex situations where this approach does not fit well, but I hope the basic idea is helpful.