Protected Actions: Adding Extra Guards to Your Entra ID Gate!

Eggs and onions

One of the most important principles in security is ‘defense in depth.‘ Personally, I prefer to think of it as having multiple layers like an onion, rather than a single layer of protection, like an egg. While you’ve hopefully read many of our posts here, and have set up MFA, device filters, sensitivity labels, and Intune controls your clients, there’s always room for improvement. Continuously seeking additional layers for your security posture is really important because each layer presents an obstacle for bad actors trying to gain access to your systems. Every bit of protection count and you never know what will make or break your protection.

Entra ID Protected Actions

This is a hidden little gem in Entra ID when you’re looking for more layers to add. Protected Actions simply triggers an Authentication Context like we saw with PIM. This, in turn, means we are able to trigger dedicated Conditional Access policies whenever a predefined action happens. And you all should know by now that I love Conditional Access policies! 😉😍

Protected actions in practice

1. Authentication Context

To do a demo we need a scenario, and then we create an Authentication context for it.

So for this short demo: Our goal is to block changes to our Conditional Access policies for all users, except Global Admins.

First we go to “Conditional Access” – “Authentication context” and select “New authentication context“.

We then give a name and description, and make sure “Publish to apps” is enabled.

2. Assign Authentication Context to Protected Actions

Protected actions are located under “Roles & admins” – “Protected actions” and then we select “Add protected actions“.

Here we first add the Authentication context we created in step 1.

Then we add the permissions which we want protected, and they will also trigger the authentication context. There are currently 19 actions available., and they can only be assigned to one authentication context each.

Here I add the three permissions regarding Conditional Access policies. (Create, delete and update) and click “Save“,

3. Create Conditional Access policy for this action.

Now we have 3 actions from step 2 which will trigger the authentication context we created in step 1. So now we only need a Conditional Access policy which will be enforced when the authentication context is triggered.

To do this, we navigate to Conditional Access and then we try to create a new Conditional Access policy. This time we get a friendly popup which informs us that this action is now protected. 👍 Since we haven’t configured the additional requirement yet, we can simply click “Yes” to continue.

But remember we said our goal is to block any changes unless you are Global Admin, so we need a policy to enforce this. Which means we must create a new policy scoped to “All users” and add the role Global Administrator as exception.

Then we select “Authentication Context” under “Target Resources” and choose the authentication context we created in step 1. Next we select “Block access” under “Grant“, Enable policy is set to “ON” and finally we click “Create“.

This policy ensures that adding, changing or deleting a Conditional Access policy is blocked, unless you are a Global Admin. Pretty cool, right?? 🥳

Let’s try!

So to test this I’m logging in with Alex Wilber who you can see has the Security Administrator role. This means Alex can, by default, do whatever he wants with Conditional Access policies. Alex also use the light theme in this demo so it’s easier to distinguish which user is represented by which screenshot.

Alex navigates to Conditional Access policies and try to create a new policy. The same popup as before appears.

But this time, when Alex clicks “Yes” he’s blocked because he is not Global Administrator.

Alex then tries to change the Conditional Access policy, but he is denied from this as well, as the editing of Conditional Access policies are now limited to Global Administrators.

I imagine Alex is slightly frustrated now, so now he tries to delete the Conditional Access policy which blocks him. But I’m sure you can imagine what happens next. 😉 Yes, he is blocked again.

Sounds too good to be true? Well, I’m afraid that it is. 😱

The disadvantages 🙁

1. Configuring protected actions requires the Conditional Access Administrator (or higher) role. Meaning that anyone who can add/change/delete a Conditional Access policy, can also add/change/delete protected actions! This will effectively removes the protection I just demonstrated above. This extra layer, when applied to Conditional Access, will at best only delay anyone trying to add/change/delete a conditional access policy. As for the demo above, when Alex finds and reads this blog post, he knows exactly how to circumvent this protection. 😉

However: There are other protected actions which does not relate to Conditional Access policies and they can be very useful for protecting those areas. Like prevent changes to B2B settings or make sure admins can’t permanently delete objects which are soft-deleted.

2. The list of protected actions is pre-defined by Microsoft and currently you can NOT add your own protected actions. At the moment there are the following 19 actions available for protection:

• 3 for Conditional Access
• 11 for cross-tenant access (B2B and cross-tenant access policies)
• 1 for permanently deleting objects which are already soft-deleted
• 3 for named locations in Conditional Access.
• 1 for updating authentication context for role-delegations.

More details about them are found here.

3. This feature from Microsoft provides enhanced granular control and additional layers of security. However, the most impactful limitation lies in the relatively short list of actions available for protection. Expanding this list would significantly improve the utility of the feature. I really hope Microsoft will address this limitation promptly to fully leverage the potential of this security enhancement.

4. This is related to the first point but it’s worth repeating: Adding/changing/deleting protected actions should require a higher privileged role (for example Privileged Role Administrator or Global Administrator). Conditional Access policies are the centerpiece of identity security in M365/Entra and I consider it critical to protect its configuration for any unsupervised changes. With a higher requirement for Protected Actions, we could protect our Conditional Access policies as demonstrated in the earlier example.

Conclusion

In conclusion, Entra ID’s Protected Actions offer an additional layer of security by leveraging Authentication Contexts and Conditional Access policies. While this feature enhances security, it is not without its limitations. The lack of requirement for higher privileged roles to configure Protected Actions, and the limited number of actions available for protection, are significant drawbacks. However, by understanding these limitations and implementing Protected Actions thoughtfully, organizations can add valuable layers to their security posture.

Remember: It’s about the onion, not the egg!