I am trying to create a service principal from azure cli.
az login --service-principal -u servicePrincipalGuid -p spPassword --tenant tenantGuid
az ad sp create-for-rbac --skip-assignment
It works if i assign to the service principal Global administrator but it does not work with the Application Administration which according to the documentations should be sufficient.
I am wondering what roles/permissions are needed to be able to create a service principal without global administrator?
I can reproduce your issue, it is really weird, based on my knowledge, the Application administrator role should work.
The command az ad sp create-for-rbac --skip-assignment creates the app registration successfully, but it can't create the corresponding service principal. Even if I test with the command below to create service principal for the app.
az ad sp create --id '<object-id of the app registration>'
or powershell
New-AzureADServicePrincipal -AppId <object-id of the app registration>
I am wondering what roles/permissions are needed to be able to create a service principal without global administrator?
If you just want to let the command work without the global admin, you could add Application.ReadWrite.All permission of Azure Active Directory Graph like below, then it will work.
Related
I am testing an environment where I have the credentials of a service principal of an application. My next step is to identify the objects owned by the application or the resources that the app can access.
I could get similar details for an AD user through the cli command
ad signed-in-user list-owned-objects
Running the same command when signed-in with the credentials of the sp results in the following error
Resource not found for the segment 'me'.
My use-case is to enumerate the SP account to understand its access rights in the subscription. Can someone help me out with the right set of azure cli commands.
I tried to reproduce the same in my environment and got below results:
I created one service principal with Storage Blob Data Contributor role at storage account scope like below:
az ad sp create-for-rbac --role "Storage Blob Data Contributor" --name <spname> --scopes /subscriptions/<subID>/resourceGroups/<rgname>/providers/Microsoft.Storage/storageAccounts/<storaccname>
Now I logged in to Azure account successfully using above service principal credentials:
az login --service-principal -u appID -p password --tenant tenantID
When I ran the same command to get the resources that the app can access, I got same error as below:
az ad signed-in-user list-owned-objects
To list RBAC roles assigned to a service principal, you can make use of below command:
az role assignment list --assignee <service_principal_ID> --all
If your use case is to list all the resources/objects a service principal can access/own, currently there is no command available particularly for that.
To know more in detail, you can check below reference:
For a given Azure AD Service Principal, Get a list of the Azure Objects and Rights by AlfredoRevilla-MSFT
Been looking for a while but couldn't find the answer. I've been using service principle on my azure devops to modify my azure infrastructure via piplines (proper permissions). I need to run some of the commands locally using powershell, for example delete some of my azure roles.
Is there a way to use my service principle's permissions via cli / powershell to achieve what I'm looking for? Cannot do it via Connect-Azure as my user account's role has insufficient permissions. I need to do it with service principle.
Yes, you can login to the Azure CLI with a Service Principal.
To sign in with a service principal, you need:
The URL or name associated with the service principal
The service principal password, or the X509 certificate used to create the service principal in PEM format
The tenant associated with the service principal, as either an .onmicrosoft.com domain or Azure object ID
az login --service-principal -u <app-id> -p <password-or-cert> --tenant <tenant>
https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli#sign-in-with-a-service-principal
I'm trying to add Azure CDN as a service account, in order to connect it to KeyVault.
Following the official guide and other suggestions such as Can't add Microsoft.Azure.Cdn service principal to Key Vault access policies
However this command:
New-AzureRmADServicePrincipal -ApplicationId "205478c0-bd83-4e1b-a9d6-db63a3e1e1c8"
is giving me this error:
New-AzureRmADServicePrincipal : When using this permission, the backing application of the service principal being created must in the local tenant.
Even after I've set the context to the correct tenant using Set-AzureRmContext -TenantId xxx.
any help is appreciated!
The error
When using this permission, the backing application of the service principal being created must in the local tenant.
is reported when you don't have sufficient permissions in AAD to add service principal for application defined in different tenant. This is case of e.g. normal user, who does not have any specific Azure Active Directory Role. With Global Administrator or Application Administrator (or possibly other roles) the command would succeed (please note that these are AAD Administrative Roles, not RBAC roles which are used for resources).
The same error could be reported by az cli call to create principal:
az ad sp create --id 205478c0-bd83-4e1b-a9d6-db63a3e1e1c8
I am trying to create a release in AzureDevops that checks the expiration of SP secrets and then updates them if necessary. I have the part that does the check:
param (
[string]$SpId
)
$SpSecret
$SpEndDate = az ad sp credential list --id $SpId --query "[].{Key:endDate}" -o tsv
((Get-Date $SpEndDate).AddDays(-30) -lt (Get-Date)) {
#Set a new secret value if it is about to expire
$SpSecret = az ad sp credential reset --name $SpId --query password -o tsv
}
Write-Host "##vso[task.setvariable variable=var01;Secret=true]$SpSecret"
Write-Host $env:Secret
The issue now is that the service connection does not have the permissions to run "z ad sp credential reset". I have looked at the connection and don't see a permission that will work. Any suggestions?
When you create the Azure Resource Manager service connection to use the AzureCLI, the system will create an AD App for you automatically, check this link.
If you use this service connection with AzureCLI, it will use the credential of the service principal of the AD App in your tenant. For the concept of service principal and AD App, see this link.
To fix the issue, navigate to the Azure Active Directory in the portal -> App registrations -> All applications -> find the application corresponding to the service connection, its name should be like organizationname-projectname-513f22f1-befd-xxxxxxcfe90f1. Then click it -> add the permission like the screenshots(Note: your user account need the admin role to click the Grant admin consent button, e.g. Global admin ).
After granting the permission, wait for a while, the service principal of the service connection will be able to create the AD App, the Azure CLI task should work fine.
The Application.ReadWrite.All permission will allow the service principal to create, read, update and delete all applications and service principals. If you want to avoid the security problem, you can also use the powershell to add the service principal of the service connection as an Owner to the service principal which you want to reset credential. Then just need to add Application.ReadWrite.OwnedBy permission in the screenshot above.
Navigate to the organizationname-projectname-513f22f1-befd-xxxxxxcfe90f1 app in the portal -> click the Managed application in local directory as below.
Then copy the Object ID in the screenshot.
Then use the powershell below(At least you need to be the Owner of the target App to run the command).
Add-AzureADApplicationOwner -ObjectId <ObjectId of the app which corresponding to the service principal> -RefObjectId <ObjectId of the service connection corresponding service principal>
Besides: At first, I suppose Add-AzureADServicePrincipalOwner is enough, but per my test, it does not work, looks may be Application.ReadWrite.OwnedBy does not allow to operate on the service principal corresponding to the AD App.
I am attempting to automate the registration of a new application in Azure Active Directory. Upon running the command in Azure CLI, it returns with the following error:
Insufficient privileges to complete the operation.
The command was run using a Service Principal which has Owner permissions at the Subscription level. When attempting to run other Azure AD commands (e.g. az ad app list), the same error is thrown. However, it works fine if we run commands relating to Azure API Manager (e.g. az apim list).
We have tried creating the Service Principal using both the Azure console (https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal) and CLI by running the following command but neither works.
az ad sp create-for-rbac --role Owner --name some-service-principal
Is there anything else required to perform this operation?
The Owner role you mention is part of Azure RBAC, which does not apply to Azure AD.
The Azure AD tenant is above the Azure subscriptions and has its own permissions.
You need to give the SP application permissions to MS Graph API / AAD Graph API (not sure which one the CLI is trying to use), or a directory role.
The first you give through API permissions on the app registration for the SP.
A directory role can be added through the Roles and administrators tab.
that happens because Azure AD and Azure subscription are completely unrelated in terms of permissions. You need Application Read\Write Azure AD permissions for your principal (user\service principal\application) to be able to carry out that task
https://learn.microsoft.com/en-us/graph/permissions-reference#application-resource-permissions
az ad app permission: https://learn.microsoft.com/en-us/cli/azure/ad/app/permission?view=azure-cli-latest#az-ad-app-permission-add
followed by az ad app grant: https://learn.microsoft.com/en-us/cli/azure/ad/app/permission?view=azure-cli-latest#az-ad-app-permission-grant
or you could do it using the portal, like the other answer suggests