Adsf

Elevating Security with Conditional Access and Protected Actions in Microsoft Entra ID


Elevating Security with Conditional Access and Protected Actions in Microsoft Entra ID

Overview

Protected actions in Microsoft Entra ID introduce a robust security mechanism by associating Conditional Access policies with specific permissions. When a user attempts to perform a protected action, they must first comply with the Conditional Access policies tied to those permissions. For instance, administrators updating Conditional Access policies can be required to satisfy a phishing-resistant MFA policy before proceeding.

This feature adds an extra layer of security, ensuring critical permissions are safeguarded, regardless of the role being used or how the permission was granted. Unlike role activation, where policies are enforced at the time of role enablement, protected actions enforce policies only when the protected action is performed, minimizing unnecessary prompts while maximizing security.

Why Use Protected Actions?

Protected actions help enforce stringent security measures for high-impact permissions. They are particularly useful for:

  • Strengthening Security: Requiring advanced authentication methods like passwordless MFA or phishing-resistant MFA.
  • Securing Devices: Using privileged access workstations through Conditional Access device filters.
  • Optimizing Session Controls: Applying shorter session timeouts with Conditional Access sign-in frequency settings.

License Requirements

Protected actions require a Microsoft Entra ID P1 or P2 license. Verify your subscription before enabling this feature.

Applications of Protected Actions

Protected actions can currently be applied to a limited set of permissions, including:

  1. Conditional Access Policy Management
  2. Cross-Tenant Access Settings Management
  3. Custom Network Location Rules
  4. Protected Action Management
Examples of Permissions for Protected Actions
Permission Description
microsoft.directory/conditionalAccessPolicies/basic/update Update basic properties for Conditional Access policies
microsoft.directory/conditionalAccessPolicies/create Create Conditional Access policies
microsoft.directory/conditionalAccessPolicies/delete Delete Conditional Access policies
microsoft.directory/conditionalAccessPolicies/basic/update Update basic properties for conditional access policies
microsoft.directory/conditionalAccessPolicies/create Create conditional access policies
microsoft.directory/conditionalAccessPolicies/delete Delete conditional access policies
microsoft.directory/crossTenantAccessPolicy/allowedCloudEndpoints/update Update allowed cloud endpoints of the cross-tenant access policy
microsoft.directory/crossTenantAccessPolicy/default/b2bCollaboration/update Update Microsoft Entra B2B collaboration settings of the default cross-tenant access policy
microsoft.directory/crossTenantAccessPolicy/default/b2bDirectConnect/update Update Microsoft Entra B2B direct connect settings of the default cross-tenant access policy
microsoft.directory/crossTenantAccessPolicy/default/crossCloudMeetings/update Update cross-cloud Teams meeting settings of the default cross-tenant access policy
microsoft.directory/crossTenantAccessPolicy/default/tenantRestrictions/update Update tenant restrictions of the default cross-tenant access policy
microsoft.directory/crossTenantAccessPolicy/partners/b2bCollaboration/update Update Microsoft Entra B2B collaboration settings of cross-tenant access policy for partners
microsoft.directory/crossTenantAccessPolicy/partners/b2bDirectConnect/update Update Microsoft Entra B2B direct connect settings of cross-tenant access policy for partners
microsoft.directory/crossTenantAccessPolicy/partners/create Create cross-tenant access policy for partners
microsoft.directory/crossTenantAccessPolicy/partners/crossCloudMeetings/update Update cross-cloud Teams meeting settings of cross-tenant access policy for partners
microsoft.directory/crossTenantAccessPolicy/partners/delete Delete cross-tenant access policy for partners
microsoft.directory/crossTenantAccessPolicy/partners/tenantRestrictions/update Update tenant restrictions of cross-tenant access policy for partners
microsoft.directory/namedLocations/basic/update Update basic properties of custom rules that define network locations
microsoft.directory/namedLocations/create Create custom rules that define network locations
microsoft.directory/namedLocations/delete Delete custom rules that define network locations
microsoft.directory/resourceNamespaces/resourceActions/authenticationContext/update Update Conditional Access authentication context of Microsoft 365 role-based access control (RBAC) resource actions

How Protected Actions Differ from Privileged Identity Management (PIM)

While both Protected Actions and PIM allow for Conditional Access enforcement, they operate at different levels:

  • PIM Role Activation: Enforces policies during role activation, protecting access comprehensively across all actions performed with the role.
  • Protected Actions: Enforces policies only when specific high-impact actions are attempted, regardless of user roles.

These two features can be combined for layered security coverage.

Application Compatibility with Protected Actions

Protected actions require applications to handle Conditional Access policies appropriately. Supported applications include:

  • Microsoft Entra Admin Center
  • Microsoft Graph PowerShell
  • Graph Explorer

Some applications, like Azure PowerShell and Azure AD PowerShell, may not support protected actions and will fail when attempting such operations. For custom applications using the Microsoft Graph API, ensure proper handling of step-up authentication challenges.

Best Practices for Using Protected Actions

  1. Maintain an Emergency Account: Exclude an emergency account from Conditional Access policies to prevent accidental lockouts.
  2. Migrate Risk Policies to Conditional Access: Replace legacy Entra ID Protection risk policies with Conditional Access policies.
  3. Use Named Network Locations: Implement named network locations instead of relying on MFA trusted IPs.
  4. Avoid Identity-Based Blocking: Use protected actions to enforce additional security requirements rather than blocking access based on group membership or identity.

Step-by-Step Guide to Implement Protected Actions

To configure and enforce protected actions, follow these steps:

Milestone-1 Check Permissions

Ensure you have the Conditional Access Administrator or Security Administrator role to configure this policy.(Always use Least privileged access)

Milestone-2 Configure a Conditional Access Policy

Create a Conditional Access authentication context and assign policies (e.g., passwordless MFA, Phishing Resistant MFA etc).

If an existing policy already includes an authentication context, you can proceed to the next section.

To create Authentication Context :

Sign in to the Microsoft Entra admin center

Go to Protection > Conditional Access > Authentication context > Authentication context.
Entra ID Authentication contexts

Click New authentication context to open the Add authentication context pane.
Enter a name and description for the authentication context, then click Save.
Add authentication context

Troubleshooting Tip:  If no authentication context values are available when attempting to select one in a Conditional Access policy, Ensure  Enable Authentication Context for the Tenant  & "Publish to Apps" is Enabled 

Let’s set up a Conditional Access (CA) policy to require a Conditional Access Administrator to meet the following conditions for the Protection Actions:

  1. Phishing-Resistant MFA: Enforce the use of a FIDO key for authentication.
  2. Sign-In Frequency: Require reauthentication every time the administrator attempts to modify a CA policy.
Note: Entra ID accounts for up to five minutes of clock skew when "Every time" is selected in a Conditional Access policy. This means that within the same browser session, changes can be made without reauthentication if the browser is refreshed within the five-minute skew window. However, if the browser refreshes after this time, the user will need to reauthenticate using the configured phishing-resistant MFA method, such as a FIDO key, as required by the policy(In my example).

For Configuring CA policy Navigate to the Policies section.
Click on New Policy to create a new Conditional Access policy.
Give the policy a meaningful name and select the specific user(s) to be included in its scope.

Entra CA Policy User Assignment

In the Target resource section, select Authentication context and choose the authentication context we created earlier.
CA Policy Target resources

Next, select the Grant control and set it to Require authentication strength. Then, choose a phishing-resistant MFA method, such as a FIDO2 security key.
Grant control set it to Require authentication strength

Finally, under the Session section, set the Sign-in frequency to Every time.

Sign-in frequency to Every time


After configuring all the options, set the Enable Policy toggle to On to activate the policy.
Then Choose Save Button

Enable Policy

Note: If you attempt to meet the requirements of the Conditional Access policy but the policy is never satisfied, and you are repeatedly prompted to reauthenticate, it may be because the policy was created but not enabled. Ensure the policy is set to On. If the policy is in Off or Report-only mode, protected action requests will continue to prompt for reauthentication without applying the intended controls.

Milestone-3 Assign Protected Actions

Map Conditional Access authentication contexts to relevant permissions.

Follow these steps:

Access Protected Actions
Select Identity > Roles & admins > Protected actions.

Entra ID Protected actions


Click Add protected actions to create a new protected action.
If the option is disabled, ensure you have the Conditional Access Administrator or Security Administrator role.
In Conditional Access Authentication Context
Choose a preconfigured Conditional Access authentication context.
Conditional Access Authentication Context Selection

Select Permissions to Protect
Click Select permissions, then choose the permissions you want to protect with the Conditional Access policy.
In my example, I will protect the following Conditional Access modification permissions: Update, Create, and Delete. To do this, I will select these specific permissions from the list. Currently, protected actions support a total of 19 permissions.

Protected actions Permissions to Protect
After selecting the permissions, click Add and then Save.
Save Protected actions

Milestone-4 Test Protected Actions

When a user attempts to perform a protected action, they must satisfy the requirements of the assigned Conditional Access policy. This section illustrates the user experience when prompted to comply with the policy. In this example, the user is required to authenticate using a FIDO security key before making updates to Conditional Access policies.

Since the Sign-in Frequency is configured to "Every time," the user will be prompted to reauthenticate for each action. However, a 5-minute Entra clock skew delay is accounted for. Within the same browser session, as long as the page is not refreshed during this window, the user can perform additional actions without being prompted again.

Sign in to the Microsoft Entra admin center using the account subject to the policy.
Navigate to Protection > Conditional Access.

Choose Create New Policy

Entra ID Conditional Access New Policy

The user is presented with an additional prompt stating, "Additional steps required. Press Yes to continue."
Additional steps required

The user will be redirected to the Entra ID authentication page and prompted to enter a password. Since the user has Passkey configured as a passwordless and MFA authentication method, they can choose an alternative sign-in option and proceed with Passkey authentication.

Details on Passkey registration and configuration are thoroughly documented in my previous blog: Enable Passkeys (FIDO2) in Microsoft Entra ID.

Entra ID authentication page

Choose Security Key options it will be automatically redirected to next page

Security Key options

At this stage, an OS prompt for security key verification will appear. The browser window will pause and wait until the security key verification process is successfully completed.

security key verification process

On the Windows Security screen, select Security Key.

Windows Security screen

You will be prompted to enter the PIN configured for your FIDO2 security key. Enter the PIN and click OK to proceed.
FIDO2 Key PIN Verification

After the PIN is verified, a prompt will appear instructing you to touch the FIDO key to complete the gesture verification.
FIDO2 Key gesture verification

After successful authentication, the Stay Signed In screen will appear based on your Entra ID organization's settings. Select your preferred option and proceed.
Stay Signed In

Now, when you select Create New Policy, the policy creation wizard will open, as the phishing-resistant MFA requirement has already been satisfied.
Create New CA Policy

We can now proceed to create the policy.
New CA Policy Wizard

Within the same session, you can now delete or modify any Conditional Access policy without reauthenticating, provided the browser is not refreshed within 5 minutes. If the browser is refreshed after 5 minutes, you will need to authenticate again due to the configured sign-in frequency.
Delete CA Policy Confirmation

After the 5-minute window, we refreshed the browser and attempted to delete or modify a Conditional Access policy. As expected, the following prompt appeared, requesting reauthentication in accordance with the configured protected action.
CA Protected action Confirmation for CA Policy Delete, Modify

Remove Protected actions

Removing protected actions is a straightforward process:

Navigate to Identity > Roles & admins > Protected actions.
Locate and select the permission you wish to remove.
Unassign the Conditional Access policy from the associated authentication context

Pro Tips for Troubleshooting Protected Actions

These tips can help identify and resolve common issues when working with protected actions in Microsoft Entra ID.

No Sign-In Prompt for Protected Actions?

Cause 1:
The user is not assigned to the Conditional Access policy applied to the protected action.

Solution 1:
Use the Conditional Access What If tool to verify the user's policy assignment

  • Select the user and the authentication context linked to the protected action.
  • Click What If and ensure the expected policy appears in the Policies that will apply table.
  • If the policy doesn’t apply, adjust the user assignment condition in the policy and add the user.
Cause 2:
The user has already satisfied the policy requirements earlier in the same session (e.g., completed multifactor authentication).

Solution 2:

Check Microsoft Entra sign-in events for detailed session information, including whether the user has already completed MFA. Additionally, review the policy details page to confirm the authentication context was requested.

PowerShell Error When Performing a Protected Action

Symptom:
An error occurs when using PowerShell for a protected action, and no Conditional Access policy prompt is displayed.

Cause:

Microsoft Graph PowerShell supports step-up authentication required for policy prompts, whereas Azure PowerShell and Azure AD Graph PowerShell do not.

Solution:

Ensure you are using Microsoft Graph PowerShell to perform the action.


Known Limitations and Recommendations

  • Terms of Use or Custom Controls Creation: These actions temporarily bypass Conditional Access policies during setup. Remove policy enforcement during the creation phase, then reapply it once the setup is complete.
  • Third-Party Applications: Ensure custom applications are updated to handle Conditional Access policy requirements to avoid disruptions.

Conclusion

Protected Actions in Microsoft Entra ID, combined with Conditional Access, provide a robust framework to secure critical permissions and enhance organizational security. By configuring policies effectively, you can ensure that high-impact actions are protected, offering greater control and compliance. Start implementing these best practices today to strengthen your security posture.

Post a Comment

0 Comments

Add

Ad Code