Blog Post

Core Infrastructure and Security Blog
6 MIN READ

Azure AD: Custom Application Consent Policies

Eric_Woodruff's avatar
Eric_Woodruff
Icon for Microsoft rankMicrosoft
Feb 05, 2021

 

Hey folks, Eric Woodruff here – a Customer Engineer who lives in the world of Azure Active Directory.

 

Today we are going to be examining custom app consent policies in Azure Active Directory, and how you can leverage them for some advanced and granular consent policies within your Azure AD tenant.

 

We won’t really be diving into the basics of application consent today, but it’s increasingly becoming a topic of discussion with customers, to ensure that they are keeping their organization secure and that they have insight and control over what applications their end users are accessing with their organization identities. For a bit more background on application consent, as well as why you should be aware of it within your organization, refer to some of our docs – and perhaps the future will hold further blog posts discussing such.

Configure how end-users consent to applications using Azure AD | Microsoft Docs

Detect and Remediate Illicit Consent Grants - Office 365 | Microsoft Docs

 

Background

For customers that want to restrict the ability for end users to grant consent to applications, the trade-off between security and usability starts to come into play.

 

We have multiple options to help customers try and find this balance – the ability for organizations to specify permissions considered low impact, or from verified publishers. And we have the ability for organizations to enable the preview feature of admin consent workflows – when a user needs an app, a request will be sent to specified administrators to approve (or deny) it. And for most of our customers these solutions fit their business needs.

 

We have a subset of customers that wish to restrict the ability for end users to be able to onboard new applications into the organization and require that the end users still must consent to the delegated permissions before being able to use the application. With a custom app consent policy, we can meet these needs.

 

Problem Scenario

In our demo Azure AD tenant, we want to allow for users to be able to perform a delegated user consent for the Fabrikam B2C Enterprise Application – in your Azure AD tenant this could be any Enterprise App that requires user consent.

 

We have already gone through the process of onboarding the application into Azure AD, but we still want to require the users to accept the delegated permissions when accessing this application.

 

In our tenant, we have disabled the ability for users to consent to apps accessing data on their behalf. And while the admin consent workflow would allow for granting permissions, that process also performs an Admin consent grant, so subsequently users would be able to access the application without needing to consent to the permissions themselves.

 

The app consent approval workflow that just won’t fit our business requirements.

 

Implementation

 

1 | Revoke Any Existing Permissions

Depending on how the application was onboarded, there may be a pre-existing set of permissions already accepted that we may want to remove; if this does not fit your case then just move on to step 2.

 

Luckily, Azure AD already provides an easy means of giving you a PowerShell snippet to revoke existing approvals. From within the Enterprise Application, if you select Permissions under the Security section of the applications blade, and within the details blade, select Review permissions at the top, and then select This application has more permissions than I want. There will be a PowerShell script presented that you can run to remove all pre-existing permission grants.

 

2 | Build A Custom Application Consent Policy

 

2.1 | Examining Existing Policies

Now that we have a fresh slate for our application, we are ready to build a custom app consent policy.

 

Ensure that we are using the latest version of the Azure AD Preview PowerShell module, connect to your Azure AD tenant.

 

After connecting to Azure AD, we can get familiar with the policies that already exist in our tenant; all customers will have some out of the box consent policies within their tenant, as we can see when we enumerate them:

 

Get-AzureADMSPermissionGrantPolicy | ft Id,DisplayName,Description

 

 


2.2 | Create New Policy

Now that we see what policies already exist, we can create our new policy:

 

New-AzureADMSPermissionGrantPolicy `
 -Id "fabrikam-b2c-app" `
 -DisplayName "Fabrikam B2C App Consent Policy" `
 -Description "Custom consent policy for Fabrikam B2C App."

 

 

After creation, we can enumerate our policies again and verify creation:

 

2.3 | Create Policy Conditions

Now that we have the policy, we must create the policy conditions that will be defined within it. When defining our policy, we have several conditions we can use to create include and/or exclude conditions. I won’t be diving into all those conditions here, but they are notated in our documentation:

Manage app consent policies in Azure AD | Microsoft Docs

 

In our case, we are going to build a policy that is specific to the ClientApplicationIds condition, which will contain the Application ID that is assigned to the Fabrikam B2C Application in our tenant – the Application ID will be unique for each application in a tenant.

 

New-AzureADMSPermissionGrantConditionSet `
 -PolicyId "fabrikam-b2c-app" `
 -ConditionSetType "includes" `
 -PermissionType "delegated" `
 -ClientApplicationIds "<application-id>"

 

 

3 | Create a Custom Azure AD Role

Now that we have our policy defined, we need to create a custom role within Azure AD to assign it to. When we create this custom role, we will be assigning the custom app consent policy to the role – this will be the only action associated with it.

 

We must create a custom role as we cannot scope an app consent policy to a group or user directly.

Using a code block from our public documentation, we are going to build this role through PowerShell:

 

# Basic role information
$displayName = "Fabrikam B2C Role"
$description = "For access to Fabrikam B2C Application."
$templateId = (New-Guid).Guid
 
# Set of permissions to grant
$allowedResourceAction =
@(
 "microsoft.directory/servicePrincipals/managePermissionGrantsForSelf.fabrikam-b2c-app"
  )
$rolePermissions = @{'allowedResourceActions'= $allowedResourceAction}
	 
# Create new custom admin role
$customAdmin = New-AzureADMSRoleDefinition -RolePermissions $rolePermissions `
 -DisplayName $displayName -Description $description `
 -TemplateId $templateId -IsEnabled $true 

 

 

Looking at the code presented, line 9 is the important piece, where we can see that we are giving the ability to manage permission grants for self to the role, relative to what applications would then be specified within the policy.

 

One thing to point out for this snippet of code – if you refer to documentation on setting this, we refer to policy ID, which in this case is the name, as you can see in our example fabrikam-b2c-app. People (including this author) may initially get tripped up and think ID = something like the Object ID for the policy, which is not was we are referencing in this case.

 

4 | Assign Users to the Custom Role

The last step is to assign users to the custom role. From a management perspective it may seem arduous to think about having to assign every relevant user in your organization to this role.

 

Luckily, with cloud the ability to use cloud groups for role assignment (in public preview at the time of this writing), we can simply assign a group to this role – for my test tenant I’m using an existing group that already contains all the relevant employees. The snippet to assign a group to the role assignment is as follows:

 

New-AzureADMSRoleAssignment -ResourceScope "/" -DirectoryScopeId "/" `
 -RoleDefinitionId "5001e3d6-015c-44b0-a680-6325e70d9739" `
 -PrincipalId "e143c731-4dbd-4312-ac6a-2eaac9cef1c3"

 

 

End Result

Now that we have created the policy, assigned it to a custom role, and have users scoped to that role by group membership, they are now able to consent to just this one specific application, without requiring administrative consent grant.

 

Now we are in business with delegated application consent for just this one application.

 

 

 

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

 

Updated Feb 05, 2021
Version 4.0
  • Dean_Gross's avatar
    Dean_Gross
    Silver Contributor

    danstw what version of the module do you have? I have 2.0.2.136 of AzureADPreview and I had to use 

    New-AzureADMSRoleAssignment -ResourceScope '/' -RoleDefinitionId $roleDefinition.Id -PrincipalId $group.Id -DirectoryScopeId '/' which contains an undocumented DirectoryScopeID parameter 

  • I'll take a look at getting this article updated with the syntax, looks like things have changed since I first wrote it.

  • danstw's avatar
    danstw
    Copper Contributor

    Thanks for the article, Eric. A few comments/observations, both relating to step 4:

    1. The version of New-AzureADMSRoleAssignment I used didn't like the ResourceScope parameter. I had to omit it.
    2. Since you're already storing your new role definition in the 'customAdmin' variable, it'd be much easier for readers to follow if you modified your New-AzureADMSRoleAssignment to read as follows:
    New-AzureADMSRoleAssignment -DirectoryScopeId "/" `
     -RoleDefinitionId $customAdmin.id `
     -PrincipalId "e143c731-4dbd-4312-ac6a-2eaac9cef1c3"

    Regards,

    Daniel

  • gduke's avatar
    gduke
    Copper Contributor

    Eric_Woodruff Is there an easy way to assign the role to the entire organization? Something analogous to Authenticated Users or Domain Users in an on-prem AD environment? I could create some dynamic AAD groups if I need to, but wondered if such an object already exists.

  • ajanes-arc's avatar
    ajanes-arc
    Iron Contributor

    Would this system also work for allowing specific admins to grant access to specific policies for the entire organization? For example, I want the owners of each application that the permissions touch to be the ones to approve the admin consent for the user. Then, each application owner knows exactly what is accessing their APIs.

  • allesglar's avatar
    allesglar
    Copper Contributor

    Is there a way to give permission to the custom role for more than one service principals? We want to allow delegated consent for endusers only for "X" applications but have just one role with the consent permissions on all of them.

     

    Thank you in advance!