Protected Actions for Azure AD Conditional Access Policies

Protected Actions are a New Method to Highlight Specific Administrative Actions

Over the last year or so, Microsoft has pumped out a set of enhancements to make Azure AD conditional access policies more flexible and powerful. Changes such as token protection (to help address the threat of token theft) and authentication strength (to insist on a specific form of multi-factor authentication for a connection) are good examples of what’s going on.

The latest preview defines a set of “Protected actions” for use with conditional access. The preview associates an authentication context (previously used to mark sensitive SharePoint Online sites) with administrator actions in a conditional access policy. When active, the policy insists that administrators who wish to perform actions specified in the policy must meet specific requirements. For example, instead of satisfying a multi-factor authentication challenge with the Microsoft authenticator app, the policy might force administrator to use a FIDO2 key before Azure AD allows them to perform an action.

Limited Set of Protected Actions for Preview

For now, the preview supports seven protected actions. Three are related to named locations; four cover management of conditional access policies. The set is enough to let people understand the concept of what Microsoft is trying to do and I expect Microsoft to add more protected actions over time.

Using Protected Actions

To start, go to the Conditional Access section of the Microsoft Entra admin center and define an authentication context. The easiest way to think about an authentication context is to regard it as a tag to mark something to protect with a conditional access policy. In this case, the tag links some protected actions with a policy. When Azure AD assesses connections, it knows that anytime accounts within the scope of the policy try to perform a protected action, their connection must meet the conditions set in the policy. A tenant can define up to 25 authentication contexts to use as they wish. To test protected actions, I created an authentication context called CAPolicy.

Next, create a conditional access policy to use the new authentication context. Figure 1 shows what I used. The policy covers some selected users and specifies the newly-created authentication context. The access control requires passwordless MFA.

Conditional access policy to use protected actions
Figure 1: Conditional access policy to use protected actions

The next step is to add protected actions to the authentication context. Open the Roles & Admins section of the Entra admin center and select Protected actions. Select the authentication context and then add protected actions (referred to as permissions in the GUI). You only need to add a single action to make the conditional access policy effective. I chose the four actions related to conditional access policies (Figure 2).

Selecting protected actions to link to an authentication context
Figure 2: Selecting protected actions to link to an authentication context

Testing Protected Actions

Now sign in as one of the accounts within the scope of the conditional access policy without using passwordless authentication and try to amend the settings of a conditional access policy (one of the four protected actions selected above). You can amend settings like adding a new authentication context or changing the accounts and groups within the scope of the policy, but you can’t save updates to a conditional access policy through the GUI (Figure 3) or with PowerShell (using the Microsoft Graph PowerShell SDK).

Blocking protected actions
Figure 3: Blocking protected actions

If the account is enabled for multi-factor authentication and can satisfy the challenge requirements set by the policy, Azure AD displays a “click here to reauthenticate” banner to allow the user to go through “step-up authentication” and meet the requirements. In the example shown in Figure 3, the account isn’t MFA-enabled and therefore cannot authenticate in the manner set by the policy, which is why Azure AD simply disables updates.

For more information, consult the online documentation.

Solid if Limited Concept (for Now)

Protected actions is a preview, with limited capabilities due toa small set of selectable actions. However, there’s enough there to see how valuable this concept might be if Microsoft expands the set of protectable actions to cover more features available through the Microsoft Entra admin center and perhaps even the Azure admin center.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Microsoft 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

One Reply to “Protected Actions for Azure AD Conditional Access Policies”

  1. Tony do you know if this works with PIM? For example, day to day I may have my admin cloud account activated for Read type roles. But to make a change I’d elevate and activate a role such as global admin for which I am eligible. Quite a few things don’t currently respond to this use case.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.