Create Azure AD App Registration with PowerShell–Part 2

In my previous post I started with the basic Azure AD App registration using PowerShell. I described how to set the HomePage URL, Reply URLs and even create an Application Key.

In this second part I’ll take you to the next level! I’ll describe how to add required permissions for your app.

Required Permissions

When your app needs access to other sources, like SharePoint Online sites or Mailboxes, you need to set permissions for your app. For example, this app can access Microsoft Graph, Windows Azure Active Directory and Office365 SharePoint Online:

And the explicit permissions set for SharePoint Online are:

Application Permissions: Your application needs to access SharePoint Online directly as itself (no user context). This type of permission requires administrator consent.

Delegated Permissions: Your application needs to access SharePoint Online as the signed-in user, but with access limited by the selected permission. This type of permission can be granted by a user unless the permission is configured as requiring administrator consent.

This can be a lot clicking if you don’t script it. So, let’s make your life much easier now!

ServicePrincipal

To add a required permission, you have to find out a couple things. First, we need to find the service principal on which the permissions are defined. And then second, we need to find the Application Permissions or the Delegated Permissions that you want to require.

To get a list of all service principals you use the cmdlet Get-AzureADServicePrincipal:

Get-AzureADServicePrincipal -All $true

If you want a specific service principal, you can filter on the DisplayName

When you store the service principal in a variable, you can then access the permissions:

$svcprincipal = Get-AzureADServicePrincipal -All $true | ? { $_.DisplayName -match "Office 365 SharePoint Online" }

# Show the Application Permissions
$svcprincipal.AppRoles | FT ID, DisplayName

# Show the Delegated Permissions
$svcprincipal.Oauth2Permissions | FT ID, UserConsentDisplayName

Now we know all available service principals and their permissions. We can use this now to set the required permissions for our app.

The tough part…

When we take a look at the cmdlet to create Azure AD Apps (New-AzureADApplication), we notice a parameter –RequiredResourceAccess is available. (https://docs.microsoft.com/en-us/powershell/module/azuread/new-azureadapplication?view=azureadps-2.0). However, this parameter takes an array of objects of type Microsoft.Open.AzureAD.Model.RequiredResourceAccess. Things will get more technical now and when you search the internet for this type of object, you may end up with some MSDN article: https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#requiredresourceaccess-type

We need two kind of objects:

• RequiredResourceAccess (which basically represents the Service Principal)
• ResourceAccess (which basically represents the Application and Delegated Permissions)

The first object, RequiredResourceAccess, has two properties to set: ResourceAppId and ResourceAccess. The ResourceAppId is the same value of the ServicePrincipal AppId property.

$svcprincipal = Get-AzureADServicePrincipal -All $true | ? { $_.DisplayName -match "Microsoft Graph" }

### Microsoft Graph
$reqGraph = New-Object -TypeName "Microsoft.Open.AzureAD.Model.RequiredResourceAccess"
$reqGraph.ResourceAppId = $svcprincipal.AppId

The property ResourceAccess is a list of required permissions. We need to create those objects first.

##Delegated Permissions
$delPermission1 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "0e263e50-5827-48a4-b97c-d940288653c7","Scope" #Access Directory as the signed in user

##Application Permissions
$appPermission1 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "62a82d76-70ea-41e2-9197-370581804d09","Role" #Read and Write All Groups
$appPermission2 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList "19dbc75e-c2e2-444c-a770-ec69d8559fc7","Role" #Read and Write directory data

The first parameter value that’s been provided when creating the ResourceAccess object is the Id of the permission. The second value indicates the permission type: Delegated Permission (value= Scope) or Application Permission (value = Role).

Once permission objects are created, those can then be set on the RequiredResourceAccess object:

$reqGraph.ResourceAccess = $delPermission1, $appPermission1, $appPermission2

OMG, more GUIDs…

But how about that Permission Id value? By the GUID itself it is hard to recognize what permission it is. I think we have a couple of approaches here.

1. You call the AppRoles and OAuth2Permissions properties to get the list of all available permissions and save it for later use. Use the required Id directly in your script and add some comments to your script what permission it is. I used this approach in this blog post.
2. Query each permission based on the DisplayName property:

   $permission = $svcPrincipal.AppRoles | ? { $_.DisplayName -match "Read and write directory data" }
   
   $appPermission1 = New-Object -TypeName "Microsoft.Open.AzureAD.Model.ResourceAccess" -ArgumentList $permission.Id,"Role"
   
   

   However, Microsoft may update the DisplayName, since this area is growing!

3. Like option 2, but now to query each permission based on the Value property.

   

   Example:

   $svcPrincipal.AppRoles | ? { $_.Value -eq "User.Read.All" }
   

   At least this feels better to read and understand than the Id (option 1), but personally I’d like to stick with option 1, because I think those GUIDs aren’t going to change.

No, I did not forget it. Yes, we still need to provide the required permissions to the New-AzureADApplication cmdlet:

$myApp = New-AzureADApplication -DisplayName $appName -IdentifierUris $appURI -Homepage $appHomePageUrl -ReplyUrls $appReplyURLs -PasswordCredentials $PasswordCredential -RequiredResourceAccess $reqGraph

If you have multiple permissions, e.g. MS Graph and SharePoint Online, supply all permission objects as an array:

-RequiredResourceAccess @($reqGraph, reqSPO)

The complete script can be download from my Assets page. Go ahead, make your life easier now!

Summary

Azure AD App registrations can be created using PowerShell. Even the required permissions can be set by providing the RequiredResouceAccess parameter. To gather all information the Get-AzureADServicePrincipal cmdlet is of great help. Along with its properties AppRoles and OAuth2Permissions.

Tags: AppRegistrationAzureADServicePrincipalPermissions