Protected Actions in Entra ID and Authentication Context in Conditional Access

 

While working on an conditional access requirement involving authentication context, I stumbled upon protected actions in Entra ID and thought of blogging my thoughts and experience working with the feature.

What are Protected actions?

Protected actions are role permissions with Conditional Access applied for added security. Conditional Access requirements are enforced when a user performs the protected action, triggering a process that will require first satisfying the Conditional Access policies assigned to the required permissions. Because the policy enforcement occurs at the time the user attempts to perform the protected action and not during user sign-in or rule activation, users are prompted only when needed.

Protected actions is currently in preview and can be applied to only a limited set of permissions spanning across the following areas:

- Conditional Access policy management

- Cross-tenant access settings management

- Custom rules that define network locations

- Protected action management

Currently supported actions are -

Source: Microsoft

As a use case, I wanted to apply additional layer of security in form of requiring MFA against the administration around Conditional Access policies so I put the protected actions to the test. Here are the steps -

Create an Authentication context if not already done

Protected actions uses a Conditional Access authentication context, so one must configure an authentication context first and then use it in a CA policy.

1. Sign in to the Microsoft Entra admin center.

2. Select Protection > Conditional Access > Authentication context > Authentication context.

3. Select New authentication context to open the Add authentication context pane.

4. Enter a name and description and then select Save as shown below.

Create Conditional Access policy

a. Sign in to the Microsoft Entra admin center.

b. Select Protection > Conditional Access .

c. Select Policies > New policy to create a new policy.

d. Create a new policy and specify the intended targeted users\groups\roles.

e. Select authentication context.

f. Select Grant condition. In my case I am selecting requiring MFA.

g. Set it to On otherwise it will not list under Protected actions.

Create protected actions

1. Navigate to Microsoft Entra admin center and select Protection > Conditional Access > Policies.

2. Select Identity > Roles & admins > Protected actions.

3. Select Add protected actions to add a new protected action.

4. Select a configured Conditional Access authentication context.

5. Select Select permissions and select the permissions to protect with Conditional Access.

6. Select Add.

7. When finished, select Save.

Testing

When an admin tries to create\update\delete the CA policies, they will be asked to carry out additional actions to satisfy conditional access requirements. They will be greeted with a messages at the bottom saying - Editing is protected by an additional access requirement. Click here to reauthenticate. At this stage, the admin can click on 'Click here to authenticate' in order to proceed.

Once the user satisfies the conditional access requirement, they will be able to perform the protected actions. In this case, approving the MFA request. The action will be captured in Entra ID sign-in logs.

Final Thoughts..

Protected actions should not be confused with Privileged permissions. While both are security-related capabilities, they have very different purposes. Privileged permissions help you elevate admin privileges while Protected actions are role permissions that can be added for additional security through Conditional Access policies. A good way to understand the Privileged permissions is by checking the description of each of the privileged roles -

As a special mention, Microsoft also recommends the following when using Protected Actions -

1. Have an emergency account when configuring Conditional Access policies for protected actions. This provides a mitigation against accidental lockout.

2. Move user and sign-in risk policies to Conditional Access as Conditional Access permissions aren't used when managing Microsoft Entra ID Protection risk policies.

3. Use named network locations as named network location permissions aren't used when managing multi-factor authentication trusted IPs.

4. Don't use protected actions to block access based on identity or group membership as they aren't intended to block use of a permission just based on user identity or group membership.