Add, test, or remove protected actions in Microsoft Entra ID
Article
Protected actions in Microsoft Entra ID are permissions that have been assigned Conditional Access polices that are enforced when a user attempts to perform an action. This article describes how to add, test, or remove protected actions.
Note
You should perform these steps in the following sequence to ensure that protected actions are properly configured and enforced. If you don't follow this order, you may get unexpected behavior, such as getting repeated requests to reauthenticate.
Prerequisites
To add or remove protected actions, you must have:
Protected actions use a Conditional Access authentication context, so you must configure an authentication context and add it to a Conditional Access policy. If you already have a policy with an authentication context, you can skip to the next section.
Select Add protected actions to add a new protected action.
If Add protected actions is disabled, make sure you're assigned the Conditional Access Administrator or Security Administrator role. For more information, see Troubleshoot protected actions.
Select a configured Conditional Access authentication context.
Select Select permissions and select the permissions to protect with Conditional Access.
Select Add.
When finished, select Save.
The new protected actions appear in the list of protected actions
Step 3: Test protected actions
When a user performs a protected action, they'll need to satisfy Conditional Access policy requirements. This section shows the experience for a user being prompted to satisfy a policy. In this example, the user is required to authenticate with a FIDO security key before they can update Conditional Access policies.
Find and select the permission Conditional Access policy to unassign.
On the toolbar, select Remove.
After you remove the protected action, the permission won't have a Conditional Access requirement. A new Conditional Access policy can be assigned to the permission.
Microsoft Graph
Add protected actions
Protected actions are added by assigning an authentication context value to a permission. Authentication context values that are available in the tenant can be discovered by calling the authenticationContextClassReference API.
Authentication context can be assigned to a permission using the unifiedRbacResourceAction API beta endpoint:
The following example shows how to get the authentication context ID that was set on the microsoft.directory/conditionalAccessPolicies/delete permission.
GET https://graph.microsoft.com/beta/roleManagement/directory/resourceNamespaces/microsoft.directory/resourceActions/microsoft.directory-conditionalAccessPolicies-delete-delete?$select=authenticationContextId,isAuthenticationContextSettable
Resource actions with the property isAuthenticationContextSettable set to true support authentication context. Resource actions with the value of the property authenticationContextId is the authentication context ID that has been assigned to the action.
To view the isAuthenticationContextSettable and authenticationContextId properties, they must be included in the select statement when making the request to the resource action API.
Troubleshoot protected actions
Symptom - No authentication context values can be selected
When attempting to select a Conditional Access authentication context, there are no values available to select.
Cause
No Conditional Access authentication context values have been enabled in the tenant.
Solution
Enable authentication context for the tenant by adding a new authentication context. Ensure Publish to apps is checked, so the value is available to be selected. For more information, see Authentication context.
Symptom - Policy isn't getting triggered
In some cases, after a protected action has been added, users may not be prompted as expected. For example, if policy requires multifactor authentication, a user may not see a sign-in prompt.
Cause 1
The user hasn't been assigned to the Conditional Access policies used for protected action.
Solution 1
Use Conditional Access What If tool to check if the user has been assigned policy. When using the tool, select the user and the authentication context that was used with the protected action. Select What If and verify the expected policy is listed in the Policies that will apply table. If the policy doesn't apply, check the policy user assignment condition, and add the user.
Cause 2
The user has previously satisfied policy. For example, the completed multifactor authentication earlier in the same session.
Solution 2
Check the Microsoft Entra sign-in events to troubleshoot. The sign-in events include details about the session, including if the user has already completed multifactor authentication. When troubleshooting with the sign-in logs, it's also helpful to check the policy details page, to confirm an authentication context was requested.
Symptom - Policy is never satisfied
When you attempt to perform the requirements for the Conditional Access policy, the policy is never satisfied and you keep getting requested to reauthenticate.
Cause
The Conditional Access policy wasn't created or the policy state is Off or Report-only.
Solution
Create the Conditional Access policy if it doesn't exist or and set the state to On.
If you aren't able to access the Conditional Access page because of the protected action and repeated requests to reauthenticate, use the following link to open the Conditional Access page.
Symptom - Error returned using PowerShell to perform a protected action
When using PowerShell to perform a protected action, an error is returned and there's no prompt to satisfy Conditional Access policy.
Cause
Microsoft Graph PowerShell supports step-up authentication, which is required to allow policy prompts. Azure and Azure AD Graph PowerShell aren't supported for step-up authentication.
Solution
Make sure you're using Microsoft Graph PowerShell.
Protecting a user's identity by monitoring their usage and sign-in patterns will ensure a secure cloud solution. Explore how to design and implement Microsoft Entra Identity protection.