Overview
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:
- Conditional Access Policy Management
- Cross-Tenant Access Settings Management
- Custom Network Location Rules
- Protected Action Management
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
- Maintain an Emergency Account: Exclude an emergency account from Conditional Access policies to prevent accidental lockouts.
- Migrate Risk Policies to Conditional Access: Replace legacy Entra ID Protection risk policies with Conditional Access policies.
- Use Named Network Locations: Implement named network locations instead of relying on MFA trusted IPs.
- 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
Milestone-2 Configure a Conditional Access Policy
Sign in to the Microsoft Entra admin center.
Go to Protection > Conditional Access > Authentication context > Authentication context.Click New authentication context to open the Add authentication context pane.
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:
- Phishing-Resistant MFA: Enforce the use of a FIDO key for authentication.
- Sign-In Frequency: Require reauthentication every time the administrator attempts to modify a CA 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
Select Identity > Roles & admins > 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.
Select Permissions to Protect
Click Select permissions, then choose the permissions you want to protect with the Conditional Access policy.
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.
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.
After successful authentication, the Stay Signed In screen will appear based on your Entra ID organization's settings. Select your preferred option and proceed.
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.
Remove 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
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.
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.
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.
0 Comments