User consent settings are now more fine-grained than just on/off. Instead, a customer can choose whether user have the permission to consent for themselves, and if so, which permission grant policy (aka "app consent policy") describes when the user will be allowed to consent (e.g. for which apps, for which permissions, etc.)
Using Microsoft Graph v1.0, this setting is stored in the permissionGrantPoliciesAssigned collection under the defaultUserRolePermissions property of the authorizationPolicy singleton.
Using Microsoft Graph PowerShell, you can retrieve the authorization policy with Get-MgPolicyAuthorizationPolicy, and update it with Update-MgPolicyAuthorizationPolicy. Both cmdlets are included in the Microsoft.Graph.Identity.SignIns module.
If the collection includes at least one value that begins with "managePermissionGrantsForSelf.", then user consent for self is enabled, subject to the permission grant policy identified by whatever follows the ".".
Examples
In this first example, *permissionGrantPoliciesAssigned is empty, indicating user consent is disabled entirely:
GET https://graph.micrsooft.com/v1.0/policies/authorizationPolicy
{
/* ... */
"defaultUserRolePermissions": {
"allowedToCreateApps": true,
"allowedToCreateSecurityGroups": true,
"allowedToReadOtherUsers": true,
"permissionGrantPoliciesAssigned": [] // <- User consent disabled entirely
}
}
In this second example, user consent is enabled, subject to the permission grant policy with ID "microsoft-user-default-low" (also note that here we're querying defaultUserRolePermissions directly):
GET https://graph.microsoft.com/v1.0/policies/authorizationPolicy/defaultUserRolePermissions
{
/* ... */
"allowedToCreateApps": true,
"allowedToCreateSecurityGroups": true,
"allowedToReadOtherUsers": true,
"permissionGrantPoliciesAssigned": [
"ManagePermissionGrantsForSelf.microsoft-user-default-low" // <- User consent enabled
]
}
We can get more details about that built-in policy (we know it's built-in because it starts with "microsoft-") by retrieving it:
GET https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies/microsoft-user-default-low
{
"id": "microsoft-user-default-low",
/* ... */
"includes": [
{
"id": "9c72ced4-50c7-4486-933e-6756d554b199",
"permissionClassification": "low",
"permissionType": "delegated",
"resourceApplication": "any",
"permissions": [ "all" ],
"clientApplicationIds": [ "all" ],
"clientApplicationTenantIds": [ "b6e5dea0-ef49-4100-9191-1bb9c16c40b0" ],
"clientApplicationPublisherIds": [ "all" ],
"clientApplicationsFromVerifiedPublisherOnly": false
},
{
"id": "8ce99f96-730c-4ebd-8397-07ee65942b97",
"permissionClassification": "low",
"permissionType": "delegated",
"resourceApplication": "any",
"permissions": [ "all" ],
"clientApplicationIds": [ "all" ],
"clientApplicationTenantIds": [ "all" ],
"clientApplicationPublisherIds": [ "all" ],
"clientApplicationsFromVerifiedPublisherOnly": true
}
],
"excludes": []
}
We can see this policy includes two condition sets:
- All delegated permissions classified "low", for apps registered in the same tenant*
- All delegated permissions classified "low", for apps with a verified publisher
*In this special built-in permission grant policy, clientApplicationTenantIds will always be the tenant ID of the tenant where the policy is being read from.