Azure - Is there any workaround for the absence of UsersPermissionToUserConsentToAppEnabled in Microsoft Graph?

kutulo
September 13, 2022
227 views
0 votes
2 Answers

I’m trying to check that users consent to apps accessing company data on their behalf is not allowed using Powershell. Originally, this is done using MSOL-CompanyInformation with UsersPermissionToUserConsentToAppEnabled. However, as deprecation gets closer for MSOL, I can not find any comparable (MgOrganization does not have the same functionality) or work around for the situation.

Any help would be appreciated. Thanks.

Answers

- vickykumar
- September 13, 2022 at 1:04 pm
- 0 votes
0
You can use permissionGrantPolicyIdsAssignedToDefaultUserRole property to update authorizationPolicy,

PATCH https://graph.microsoft.com/beta/policies/authorizationPolicy/authorizationPolicy

for more please check doc – https://learn.microsoft.com/en-us/graph/api/authorizationpolicy-update?view=graph-rest-beta&tabs=http

Note: Use of these APIs in production applications is not supported

Hope this helps

Thanks

Login or Signup to reply.

- PhilippeSignoret
- September 13, 2022 at 3:54 pm
- 0 votes
0
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.
Login or Signup to reply.