Manage app consent policies
App consent policies are a way to manage the permissions that apps have to access data in your organization. They're used to control what apps users can consent to and to ensure that apps meet certain criteria before they can access data. These policies help organizations maintain control over their data and ensure they only grant access to trusted apps.
In this article, you learn how to manage built-in and custom app consent policies to control when consent can be granted.
With Microsoft Graph PowerShell, you can view and manage app consent policies.
An app consent policy consists of one or more "include" condition sets and zero or more "exclude" condition sets. For an event to be considered in an app consent policy, it must match at least one "include" condition set, and must not match any "exclude" condition set.
Each condition set consists of several conditions. For an event to match a condition set, all conditions in the condition set must be met.
App consent policies where the ID begins with "microsoft-" are built-in policies. Some of these built-in policies are used in existing built-in directory roles. For example, the microsoft-application-admin
app consent policy describes the conditions under which the Application Administrator and Cloud Application Administrator roles are allowed to grant tenant-wide admin consent. Built-in policies can be used in custom directory roles and to configure user consent settings, but can't be edited or deleted.
Prerequisites
- A user or service with one of the following roles:
- Privileged Role Administrator directory role
- A custom directory role with the necessary permissions to manage app consent policies
- The Microsoft Graph app role (application permission)
Policy.ReadWrite.PermissionGrant
when connecting as an app or a service
To manage app consent policies for applications with Microsoft Graph PowerShell, connect to Microsoft Graph PowerShell.
Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -Scopes "Policy.ReadWrite.PermissionGrant"
List existing app consent policies
It's a good idea to start by getting familiar with the existing app consent policies in your organization:
List all app consent policies:
Get-MgPolicyPermissionGrantPolicy | ft Id, DisplayName, Description
View the "include" condition sets of a policy:
Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | fl
View the "exclude" condition sets:
Get-MgPolicyPermissionGrantPolicyExclude -PermissionGrantPolicyId "microsoft-application-admin" | fl
Create a custom app consent policy using PowerShell
Follow these steps to create a custom app consent policy:
Create a new empty app consent policy.
New-MgPolicyPermissionGrantPolicy ` -Id "my-custom-policy" ` -DisplayName "My first custom consent policy" ` -Description "This is a sample custom app consent policy."
Add "include" condition sets.
# Include delegated permissions classified "low", for apps from verified publishers New-MgPolicyPermissionGrantPolicyInclude ` -PermissionGrantPolicyId "my-custom-policy" ` -PermissionType "delegated" ` -PermissionClassification "low" ` -ClientApplicationsFromVerifiedPublisherOnly
Repeat this step to add more "include" condition sets.
Optionally, add "exclude" condition sets.
# Retrieve the service principal for the Azure Management API $azureApi = Get-MgServicePrincipal -Filter "servicePrincipalNames/any(n:n eq 'https://management.chinacloudapi.cn/')" # Exclude delegated permissions for the Azure Management API New-MgPolicyPermissionGrantPolicyExclude ` -PermissionGrantPolicyId "my-custom-policy" ` -PermissionType "delegated" ` -ResourceApplication $azureApi.AppId
Repeat this step to add more "exclude" condition sets.
After creating the app consent policy, you need to assign it to a custom role in Microsoft Entra ID. You then need to assign users to that custom role, which is attached to the app consent policy you created. For more information on how to assign the app consent policy to a custom role, see App consent permissions for custom roles.
Delete a custom app consent policy using PowerShell
The following cmdlet shows how you can delete a custom app consent policy.
Remove-MgPolicyPermissionGrantPolicy -PermissionGrantPolicyId "my-custom-policy"
Warning
Deleted app consent policies cannot be restored. If you accidentally delete a custom app consent policy, you will need to re-create the policy.
Supported conditions
The following table provides the list of supported conditions for app consent policies.
Condition | Description |
---|---|
PermissionClassification | The permission classification for the permission being granted, or "all" to match with any permission classification (including permissions that aren't classified). Default is "all." |
PermissionType | The permission type of the permission being granted. Use "application" for application permissions (for example, app roles) or "delegated" for delegated permissions. Note: The value "delegatedUserConsentable" indicates delegated permissions that aren't configured by the API publisher to require admin consent. This value can be used in built-in permission grant policies, but can't be used in custom permission grant policies. Required. |
ResourceApplication | The AppId of the resource application (for example, the API) for which a permission is being granted, or "any" to match with any resource application or API. Default is "any." |
Permissions | The list of permission IDs for the specific permissions to match with, or a list with the single value "all" to match with any permission. Default is the single value "all." - Delegated permission IDs can be found in the OAuth2Permissions property of the API's ServicePrincipal object. - Application permission IDs can be found in the AppRoles property of the API's ServicePrincipal object. |
ClientApplicationIds | A list of AppId values for the client applications to match with, or a list with the single value "all" to match any client application. Default is the single value "all." |
ClientApplicationTenantIds | A list of Microsoft Entra tenant IDs in which the client application is registered, or a list with the single value "all" to match with client apps registered in any tenant. Default is the single value "all." |
ClientApplicationPublisherIds | A list of Microsoft Partner Network (MPN) IDs for verified publishers of the client application, or a list with the single value "all" to match with client apps from any publisher. Default is the single value "all." |
ClientApplicationsFromVerifiedPublisherOnly | Set this switch to only match on client applications with a verified publishers. Disable this switch (-ClientApplicationsFromVerifiedPublisherOnly:$false ) to match on any client app, even if it doesn't have a verified publisher. Default is $false . |
scopeType | The resource scope type the preapproval applies to. Possible values: group for groups and teams, chat for chats, or tenant for tenant-wide access. Required. |
sensitivityLabels | The sensitivity labels that are applicable to the scope type and aren't preapproved. It allows you to protect sensitive organizational data. Note: Chat resource does not support sensitivityLabels yet. |
Next steps
To get help or find answers to your questions: