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.