We currently have one DevOps repository, with a functional CI/CD pipeline. We have another website hosted on a different instance (and different region) on Azure. We are trying to use our existing repo to deploy to the other Azure instance, but it is giving is the following message:
Failed to query service connection API: 'https://management.azure.com/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d?api-version=2016-06-01'. Status Code: 'Forbidden', Response from server: '{"error":{"code":"AuthorizationFailed","message":"The client '2317de35-b2c2-4e32-a922-e0d076a429f5' with object id '2317de35-b2c2-4e32-a922-e0d076a429f5' does not have authorization to perform action 'Microsoft.Resources/subscriptions/read' over scope '/subscriptions/c50b0601-a951-446c-b637-afa8d6bb1a1d'."}}'
I have tried all of the recommended trouble-shooting, making sure that the user is in a Global Administrator role and what-not, but still not luck. The secondary Azure subscription that we are hoping to push our builds to is a trial account. I'm not sure if it being a trial account matters.
I came across the same error. It turns out that, as the error message states, the service principal didn't have Read permission over the subscription. So the solution was to go to Azure Portal, select the subscription, select IAM and assign the role Reader to my service principal. Full explanation on here:
https://clydedz.medium.com/connecting-azure-devops-with-azure-46a908e3048f
I have the same problem. There are one repository and two instances of the application on the Azure portal. For the first instance, the subscription Pay-As-You-Go is used, and there were no problems for it when creating the service connection and CI/CD settings. For the second instance, a free subscription is used and when trying to create a new service connection (Azure Resource Manager) I get the same error.
I tried to do it with the permissions of Owner and Contributor
UPD: I was helped by the re-creation of the application in the azure portal
https://learn.microsoft.com/en-ca/azure/active-directory/develop/howto-create-service-principal-portal
Another option would be to save without verification if the Service Principle will not require permissions at the Subscription level. Like for example providing access to a Keyvault.
Check if the service connection for the second instance is correctly added in project settings:
Related
My requirement is to use Azure Devops services to create services connection, so I created an azure AD application in azure portal
In azure Devops project setting I created a new service connection but when I click on verify it throws me the error:
Failed to query service connection API "https://managemant.azure.com/sub/xxx?api-version=2016-06-01.status code:'status code:{"error",:{code""Authorization failed message" 'the client" with object id "does not have authorization to perform action 'microsoft.resource/sub/read,over scope'/sub/*** or scope is invalid.if access was recently granted.please refresh your credentials}}
The document I am referring to is https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#use-spn
Would appreciate any assistance on this
TIA
I tried to reproduce the same in my environment and got the same error as below:
To resolve the error, assign reader role/permission to the Azure AD Application on the subscription level like below:
Go to Azure Portal -> Subscriptions -> Select your Subscription -> Access control (IAM) -> Add role assignment
Verification is successful after assigning the role like below:
You can also assign contributor role based on your requirement.
According to the error message, you can try go to portal and find your subscription, click on Access Control (IAM) and then click on Add role assignment use the object id. And then try to create a new service connection to check if it works.
The Service Principal or Managed Identity currently you are using from Azure Devops does not have permission to create another service principal. You have to assign specific permissions for create a service principal on your Azure AD tenant. You may try providing "Application Developer" role to the ID which you are using to authenticate from Az Devops.
Please refer this MS link for reference:
Permsissions
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
I am planning to migrate my work to Azure Stack Hub. Can someone please let me know whether I can use Azure DevOps Services in Azure Stack Hub. If so please advise me on how to.
Thanks
If your Azure Stack Management URLs are not public, you'll need a Self-hosted Agent on-prem or somewhere that it can see the Azure Stack Management URLs.
The Self-Host agent will need the Azure Stack Environments created for your Azure Stack Hub e.g. AzureStackUser and/or AzureStackAdmin using the appropriate Management URL.
In Azure DevOps, create a New Service Connection for Azure Resource Manager, but make sure the Environment is set to Azure Stack.
The Server Url must be to one of the Management URLs of your Azure Stack that match the Environment you configure. This depends on what you're doing.
For Admin related configuration:
Use the Admin Management URL e.g. https:///adminmanagement.local.azurestack.external
Set the Subscription ID and Subscription Name to the Default Subscription on the Azure Stack Hub
Enter the Service Principal and Connection Details
For User related configuration:
Use the Management URL e.g. https:///management.local.azurestack.external
Set the Subscription ID and Subscription Name to the User Subscription defined on the Azure Stack Hub
Enter the Service Principal and Connection Details
NOTE: The Service Principal must have the appropriate Role on either the Default Subscription or the User Subscriptions.
Don't verify the Connection, unless the Management URLs are accessible publically
Hope this helps.
We have a release pipeline that is failing with following message:
resource ID for resource type 'Microsoft.Web/Sites' and resource name
'appservicename'. Error: Could not fetch access token for Managed
Service Principal. Please configure Managed Service Identity (MSI) for
virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400,
status message: Bad Request
We have 2 different service connections:
Azure Resource Manager using service principal authentication
Azure Resource Manager using managed identity authentication
The first one works like a charm. However, because the developer wanted to limit admin access on the Azure AD, he tried creating a managed identity authentication service connection which at first glance, since it allowed us to select the App Service, appeared to indicate it's working, until an actual deployment was triggered and it failed per the error message above.
After numerous searches online, I think this answer may be the clue to why this is failing with the managed identity authentication service connection yet succeeding with the service principal connection just fine.
I just want to confirm, is this truly the case? that a hosted agent doesn't support MSI based authentication, which is what we are using… or has that changed?
We are indeed using Microsoft agent pool.
It doesn't make sense for our app service to use a VM at this time. The use case just isn't applicable for the dashboards we have.
As it is written in the docs:
You are required to use a self-hosted agent on an Azure VM in order to use managed service identity
I assume that it was alway like that. Here we are talking abut MSI assigned to VM which serves as build agent. Not MSI which is identity of App Service. Why? Service Connection is an abstraction which makes easy authentication to your Azure Subscription. So it gives identity to VM and then when your perform some action against your Azure thanks to MSI Azure know that can perform that action. Another aption is authentication via Service Principal, but thi can be done from any VM (inlcuding MS Hosted) because it relies on Client Id and Client secret which is kept in service connections. And MSI have to be assigned to particular VM which cannot be done with MS Hosted agents.
I am just new to Azure Cloud and Devops, so forgive me if I may forget some critical info here.
So during creation of tasks for the release and selecting subscriptions, I get an error when trying to authorize the subscription (which I suspect is because of insufficient permissions associated to my account), so I go to advanced options to select the managed identity authentication.
After which no error shows now. So I set all remaining items and assign Deploy Azure App Service task. However during the running of the agent I get an error during Deploy Azure App Service step.
Error: Failed to get resource ID for resource type 'Microsoft.Web/Sites' and resource name 'sample-vue'. Error: Could not fetch access token for Managed Service Principal. Please configure Managed Service Identity (MSI) for virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad Request
I have already set my azure app service to have a system assigned managed identity, but still this error occurs. I can't find any answer, online, with regards to the error above so hoping that someone could help explain to me the problem and how to possibly fix it. My hunch now is that I may have some insufficient permissions, but I don't know what it may be.
Please try the following items:
Remove and re-add the service connection in DevOps.
Check the rights of the account on Azure subscription. Please verify if the account has at least contributor access on Azure subscriptions. Check https://learn.microsoft.com/en-us/azure/billing/billing-add-change-azure-subscription-administrator