Is it possible to assign roles and scopes to a newly created app using a Service Principal in PowerShell?

Question

I have written a module to create an app registration in Azure AD and assign roles and scopes. When using my own credentials as a Global Administrator to connect to Azure AD it works but when using a Service Principal with certificate thumbprint it returns the following

PS C:\WINDOWS\system32> New-AzureADServiceAppRoleAssignment -ObjectId "GUID" -PrincipalId "GUID"
 -ResourceId "GUID" -Id "GUID"

New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment
Code: Request_BadRequest
Message: One or more properties are invalid.
RequestId: 8ab86d25-3963-4d67-a112-44285bc74c82
DateTimeStamp: Tue, 17 Dec 2019 13:04:10 GMT
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed
At line:1 char:1
+ New-AzureADServiceAppRoleAssignment -ObjectId "GUID...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewServicePrincipalAppRoleAssignment
 at <ScriptBlock>, <No file>: line 1

Answer 1

Yes, this is possible, and for creation of the app role assignment, what you've shown in your question should work.

One of the reasons you may be getting this (not particularly useful) error message is if the service principal had already been assigned this app role.

Especially when testing, it's important to remove existing app role assignments for the same app role first, then waiting a bit (to make sure the change has replicated) before attempting to do it again.

---

Below is an important note applicable when reading app role assignments using Azure AD PowerShell and providing your own access token.

The cmdlets Get-AzureADServiceAppRoleAssignment and Get-AzureADServiceAppRoleAssignedTo call Azure AD Graph API. Azure AD Graph has a peculiar quirk where it exhibits different behavior based on whether the app ID used to get the access token is a Microsoft-owned app registration (eg the Microsoft-owned app registration for Azure AD PowerShell, used by default during Connect-AzureAD ), or an access token obtained using a regular customer-owned app registration (eg when providing your own access token using -AadAccessToken ).

When connecting with Connect-AzureAD (without passing an access token):

• Get-AzureADServiceAppRoleAssignment -ObjectId "{id}" returns the app role assignments where {id} is the object ID of the assigned service principal (ie the app which has been granted an app-only permission).
• Get-AzureADServiceAppRoleAssignedTo -ObjectID "{id}" returns all app role assignments where {id} is the object ID for the resource service principal (ie the app which exposes the app role in question).

However, when connecting with Connect-AzureAD -AadAccessToken "{token}" ... (where {token} is an access token to Azure AD Graph API, obtained with a customer-owned app registration), the behavior is reversed:

• Get-AzureADServiceAppRoleAssignment -ObjectId "{id}" returns all app role assignments where {id} is the object ID for the resource service principal (ie the app which exposes the app role in question).
• Get-AzureADServiceAppRoleAssignedTo -ObjectID "{id}" returns the app role assignments where {id} is the object ID of the assigned service principal (ie the app which has been granted an app-only permission).

To add a bit to the confusion, this issue does not need to be accounted for when adding or removing app role assignments. Both New-AzureADServiceAppRoleAssignment and Remove-AzureADServiceAppRoleAssignment can be called with -ObjectId identifying either the assigned service principal or the resource app's service principal and the commands will execute as expected.

A final note: This issue has been addressed in the equivalent APIs in Microsoft Graph API beta. When the Microsoft Graph-based PowerShell module based off of Microsoft Graph is released, you will likely want to migrate over to that module, which will have consistent behavior.