Azure Service principal insufficient permissions to manage other service principals

Question

I'm able to create a service principal either using Azure or from the portal console with the az cli.

az ad sp create-for-rbac --name "myspuser" --password "adfhrrreeuwrgwejdfgds"

Then I assign the owner role at subscription level and log-in in a powershell console.

Login-AzureRmAccount -Credential (New-Object System.Management.Automation.PSCredential ('a92b2ea2-aaaa-0000-0a0a-1238ec953226', $(ConvertTo-SecureString 'abcewior23h23ius' -AsPlainText -Force))) -ServicePrincipal -TenantId 0cedca99-00f4-40d1-aa41-80d67ece2de8;

Here I can do almost anything like deploy machines except check for other users.

When I execute

Get-AzureRmADServicePrincipal

All that I get is Get-AzureRmADServicePrincipal : Insufficient privileges to complete the operation. This works with my standard user login.

My goal is to create an automation where users can deploy a full environment via ARM templates using jenkins in their MSDN subscription. As some logins a are not supported from powershell I would like to make my users use a service principal for that. My automation requires creating a SP that will be used from a linux machine using jenkins that needs to read resource group machines properties.

What I am missing here? How can I assign a service principal user rights to manage other service principal accounts?

Joy Wang · Answer 1 · 2018-09-12T01:39:31.430

It seems you need to use Add-AzureADDirectoryRoleMember to assign directory role to your service principal.

You could choose the specific directory role that you need, refer to this link.

Note: You need to install azure ad powershell module first.

In this case, you could try to assign Application Administrator role to your service principal. (If necessary, you could assign Company Administrator role.)

Sample:

# Fetch role instance
$role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Application Administrator'}

# If role instance does not exist, instantiate it based on the role template
if ($role -eq $null) {
    # Instantiate an instance of the role template
    $roleTemplate = Get-AzureADDirectoryRoleTemplate | Where-Object {$_.displayName -eq 'Application Administrator'}
    Enable-AzureADDirectoryRole -RoleTemplateId $roleTemplate.ObjectId

    # Fetch role
    $role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Application Administrator'}
}

# Add the SP to role
Add-AzureADDirectoryRoleMember -ObjectId $role.ObjectId  -RefObjectId <your SP ObjectID>

Here is a similar issue for you to refer, see this link.

I've been testing this on with a MSDN live ID account and MSDN in from a corporate tenant. From what I saw the free AD included with the MSDN doesn't has this feature. I was not aware of this limitation. I already mentioned in my question this was thinking to use MSDN developer licenses. In my corporate AD I don't have permissions to test it. — guillem, Sep 12 '18 at 14:51
@guillem If so, seems you could not assign a service principal rights to manage other service principals. — Joy Wang, Sep 13 '18 at 00:53

Marco · Answer 2 · 2019-08-21T11:29:13.330

The owner role doesn't apply to Azure AD and the Directory Roles only apply to users. Service Pricipal = Application and not a user. Users can be linked to the service principal though, but I haven't seen an actual use for that personally..

To manage service principals with a service principal you need to assign API permissions. I can't tell you how to do this using Powershell as I have not found the commands for it, quite a shame. Hint hint microsoft azure. You go into the portal, open the application from AAD and go to API permissions. You will be able to assign permissions for both legacy Azure AD as well as MS Graph.

In my experience the legacy AAD permissions worked in more cases and offered more granularity, but I did report it as an issue and it may be changed that the MS Graph permissions are the way forward.

I know it's an old topic, but still felt like answering as it popped up in my own search for some other issue. :)

edit: Allowing a service principal API permissions to manage applications you will be able to let an application manage other applications. However, are you realy sure you want to give regular users the ability to manage these applications? It can have far going security implications depending on how much privileges you give this one service principal.

Azure Service principal insufficient permissions to manage other service principals

2 Answers2

Linked