I'm getting the below error when trying to execute below AZ Rest command.
az rest \
--method GET \
--uri "https://graph.microsoft.com/v1.0/applications/<object-id>"
Insufficient privileges to complete the operation
Below are the permissions which I have given
Do I need to add any other permissions?
I'm logged in using a Service Principal
Based on the exclamation mark visible to the right of the screenshot, I think an administrator has not granted the application permission.
You'll need an Application Admin/Cloud Application Admin/Global Admin to come in to that tab and click Grant permissions.
When you are logged in using a service principal, only the permissions with type Application will apply.
Delegated permissions only apply when you sign in using the app + a user.
Related
I'm working with an app registration that has a secret defined. Via PowerShell I am able to get the credential, but not the secret value. Function used is Get-AzADAppCredential This is expected behavior, no issue here.
To renew the secret I run two functions Remove-AzADAppCredential and New-AzADAppCredential.
I run these PowerShell cmdlets via a DevOps pipeline and use a service connection with permissions in Azure portal.
I noticed that, when we create a service connection from DevOps to Azure, the service principal gets the role Cloud application administrator automatically assigned.
This role includes the permission "microsoft.directory/applications/credentials/update".
So the above (remove + new) should work, but it does not...
DevOps returns an error:
Az.MSGraph.internal\Remove-AzADApplicationPassword : Insufficient privileges to complete the operation.
Az.MSGraph.internal\Add-AzADApplicationPassword : Insufficient privileges to complete the operation.
PS. Using Az.Resources version 5.4.0 when working with the PowerShell functions.
Anyone got any idea what I'm missing?
Thanks.
Insufficient privileges to complete the operation.
The error comes when the user doesn't have sufficient privileges in AAD and doesn't have Write permission for the selected Azure Subscription.
Note: If you have Cloud application administrator privileges of the user, this role grants the ability to manage application credentials. Users assigned this role can add credentials to an application and use those credentials to impersonate the application’s identity. If the application’s identity has been granted access to a resource, such as the ability to create or update User or other objects, then a user assigned to this role could perform those actions while impersonating the application.
Make sure to check once if you have Global Administrator Access. If you have the access you can able to Modify the secret.
Users who are assigned to the Global administrator role can read and modify every administrative setting in your Azure AD organization.
The permission issue may happen due to
The user has only guest permission in the directory
The user is not authorized to the add applications in the directory
Refer here for detailed information
To be able to update a secret on an app registration, through DevOps, using a service principal, with minimal permissions, first make the service connection owner on that random app registration.
Next, add the Application.ReadWrite.OwnedBy application API permission on the app registration that's linked to the enterprise application. Not on the app registration where the service principal was made owner.
Than renewing the secret works fine.
It remains a question though why the role Cloud application administrator isn't sufficient because microsoft.directory/applications/credentials/update is included in that role, and that should also be enough.
Getting below error while logging to container registry
Command:
docker login <MY_REGISTRY_NAME>.azurecr.io
Error Message:
Error response from daemon: Get https://<MY_REGISTRY_NAME>.azurecr.io/v2/: unauthorized: Application not registered with AAD
Go to Access Keys in Container Registry and enable the admin user, then use the autogenerated credentials to login via Docker
For me, the easiest way to get everything going was to read the documents from Docker at https://docs.docker.com/cloud/aci-integration/. Really, all you have to do is, create the container in Azure, open up PowerShell(if you haven't, install/import the azure modules,) and run the command "docker login azure." This will pop open a browser window and you can sign directly into your container from there. I haven't tried this with having multiple containers yet, as I only have a need for one so far, but I can't imagine it would be all the difficult.
For those of you who don't want to enable the admin user via the "Access Keys" section in the Container Registry, you can follow this link - https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal - to create a service principal. Running the script provided in the mentioned link generates a ID password combination that can be used with your docker login commands (give the ID as username in the docker login command). This also ensures that if you want to run the docker commands via some scripts that you have written then you can use these credentials.
The command offers the capability of assigning fixed roles to the service principals that you are creating. Roles specific to just pull or push (which includes pull) can be assigned.
The thing that I am not clear about is why don't the users added via the Azure AD can't be used in the docker login commands but using service principals works. (If anyone has an idea about it then please feel free to share).
This can happen if you use the full registry name e.g. registryname.azurecr.io as the username instead of just registryname
The error message is annoyingly incorrect!
TL;DR
Check the details for your authentication option and the login troubleshooting docs. The solution mentioned below works for individual login with Azure AD for Docker and Helm.
Although the accepted answer from #Anudeepa fixes the issue, this is not the desired purpose of the Admin account (see docs):
The admin account is designed for a single user to access the registry, mainly for testing purposes. We do not recommend sharing the admin account credentials among multiple users. All users authenticating with the admin account appear as a single user with push and pull access to the registry. Changing or disabling this account disables registry access for all users who use its credentials. Individual identity is recommended for users and service principals for headless scenarios.
So, the first address to tackle the issue should be the docs to troubleshoot login. The mentioned error message Error response from daemon: Get https://<MY_REGISTRY_NAME>.azurecr.io/v2/: unauthorized: Application not registered with AAD can have multiple causes.
Keep in mind that there are multiple options to authenticate to ACR.
I assume the question either refers to 1) Individual login with Azure AD or 2) Service principal.
My issue was with the Individual login as there is a gotcha. Your username must be 00000000-0000-0000-0000-000000000000 (this is not a placeholder for your own id). The following fixed the error for me:
USER_NAME="00000000-0000-0000-0000-000000000000"
PASSWORD=$(az acr login --name <MY_REGISTRY_NAME> \
--expose-token \
--output tsv \
--query accessToken)
echo "$PASSWORD" | docker login <MY_REGISTRY_NAME>.azurecr.io \
--username "$USER_NAME" \
--password-stdin
echo "$PASSWORD" | helm registry login tacto.azurecr.io \
--username "$USER_NAME" \
--password-stdin
I had this error unauthorized: Application not registered with AAD when during docker login I used Service Principal's DisplayName instead of ApplicationId as a value of --username.
Get-AzADServicePrincipal -DisplayName <DisplayName> | Select ApplicationId
This way you can find out your Service Principal's ApplicationId by DisplayName in Azure Powershell. You can find it on Azure Portal as well.
Like others have mentioned, you can use the admin user if you would like.
However, this might not be the ideal solution for larger organization. Instead you can use RBAC and Azure AD logins to manage access. Here are the steps I took:
Ensure you and your users have the required RBAC roles. Please refer to the following link for details: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli
If you have not done so already, download the Azure CLI: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-windows?tabs=azure-cli
Log into the Azure CLI using the following command: az login
A pop should appear allowing you to log in via your browser.
Ensure you are logged into the same subscription as your Azure Container Repository
Finally, log into your azure container repository with:
az acr login --name <your-repo-name-here>.azurecr.io
That is it! I found this solution to make collaboration far easier. Hopefully it helps!
Get credentials using az acr credential show --name testcontainerregistry
Use these credentials in docker login testcontainerregistry.azurecr.io
I have an azure account called account1 where I create an App/Principal that is across tenants visibility. I then give it some API permissions. I have another azure account account2 where I need to access resources using this app. I complete the admin consent flow for account2 by going to the following url
https://login.microsoftonline.com/<account2 domain>/adminconsent?client_id=cid1
The flow finishes and I get the tenant id back as say tid2. When I try to login from command prompt with app creds to access account2, I get an error
(it was working before and suddenly stopped working)
az login --service-principal --username cid1 --password "pwd" --tenant tid2
Error:
No subscriptions found for cid1.
EDIT: In the chat we found the issue had something to do with the terminal app used on Mac. After using the native terminal, the login was successful and the other terminal app worked as well.
You need to assign RBAC roles to the service principal in account 2.
You can do that through the Access Control (IAM) tab of the subscription by adding the necessary role to the app.
This would happen if you created a service principal and granted it access permissions to specific azure resources within a susbcription, in which case your sp will not have access to whole susbcription. I had same issue as you were facing until I tried flag "--allow-no-subscriptions". Following worked fine for me from within a container to read and update a certificate from/to azure key vault, where I granted sp read,list and import permissions.
az login --allow-no-subscriptions --service-principal --username cid1 --password "pwd" --tenant tid2
My situation is as follows: I want to create an Azure service principal. But when I try to do it with this command az ad sp create-for-rbac, I always get the error "Insufficient privileges to complete the operation."
Am I correct in assuming this appears because I was invited by a regular user to this subscription?
And in order to expand my privileges do I need to be assigned the administrator role in this subscription?
You're probably not a User Access Administrator since this is a role that needs to be set quite explicitly.
In the end, the reason is quite simple: you have "Insufficient privileges to complete the operation". You can read up on and try to Understand role definitions for Azure resources here.
az ad sp create-for-rbac requires permissions in the subscription / a resource group (Owner or User access administrator role to be specific), and in addition requires permissions in the linked Azure Active Directory to register applications (as the command creates an app registration).
My requirement is simple. I want to login to Azure through my shell script in non-interactive mode, but "az login -u username -p password" command gives the following error:
Get Token request returned http error: 400 and server response: {"error":"invalid_grant","error_description":"AADSTS70002: Error validating credentials. : SAML token is invalid. : The element with ID 'xxxxxx' was either unsigned or the signature was invalid.
Some site told me to create a service principal. Now my question is, what is a service principal, and how do I create a service principal so that I can execute my commands (for creating different resources like app gateway) from my shell script?
Please refer to this official document.
An Azure service principal is a security identity used by user-created
apps, services, and automation tools to access specific Azure
resources. Think of it as a 'user identity' (login and password or
certificate) with a specific role, and tightly controlled permissions
to access your resources. It only needs to be able to do specific
things, unlike a general user identity. It improves security if you
only grant it the minimum permissions level needed to perform its
management tasks.
If you want to create a new service principal(sp) with Azure CLi 2.0. You could login with your Azure AD user. Then execute following command.
az ad sp create-for-rbac --name {appId} --password "{strong password}"
The result like below:
{
"appId": "a487e0c1-82af-47d9-9a0b-af184eb87646d",
"displayName": "MyDemoWebApp",
"name": "http://MyDemoWebApp",
"password": {strong password},
"tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
appId is your login user, password is login password.
After the sp is created, you also need give it Contributor role, then you could manage your Azure resource.
az role assignment create --assignee <objectID> --role Contributor
Now, you could login in non interctive mode with following command.
az login --service-principal -u <appid> --password {password-or-path-to-cert} --tenant {tenant}
Service principal just work as an impersonation for user in Azure AD. Refer - https://sanganakauthority.blogspot.com/2019/04/how-to-create-service-principal-or-app.html
Using this you can perform any type of management task against Azure using REST APIs. This way you avoid need of providing credentials in pop up and hence help to automate things in Azure using REST APIs.
Here your go: Use portal to create an Azure Active Directory application and service principal that can access resources.
When you have an application that needs to access or modify resources, you must set up an Azure Active Directory (AD) application and assign the required permissions to it. This approach is preferable to running the app under your own credentials because:
You can assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.
You do not have to change the app's credentials if your responsibilities change.
You can use a certificate to automate authentication when executing an unattended script.