I want to use the Azure DevOps Extension 'Power BI Actions' for uploading a report from my Azure Repo to a Power BI Workspace. I have installed the Power BI Actions extensions on my DevOps organization.
I have also created a Service Principal on my Azure Tenant and generated a client secret for the same. The Service Principal has the permissions Tenant.ReadAll and Tenant.ReadWriteAll added but they havent been given Admin grant yet.
The Service Principal has been added as an admin to the necessary Power BI Workspace as well.
I have then created a service connection using the above Service Principal for authentication purposes as username/password method on Power BI Actions Extension does not support MFA.
My end goal is to build a CI/CD Pipeline. Currently the build pipeline works as I am able to push a .pbix file to a drop container as an artifact.
The Release pipeline which only has this one task currently fails giving me an 'Unauthorized' error message and says that the workspace does not exist. I have checked multiple times. Workspace name is correct.
Could this issue be because of the API Permissions not granted? If so am I using the right permissions? Or are there any others that are required.
The link to the extension is attached here.
Thanks
I think it is not related to azure devops and only with azure, power BI.
Just my guess, please make sure that you have added the service principal to your workspace.
Also,
Service principal only supports some read-only admin APIs. To enable
service principal support for read-only admin APIs, you have to enable
the Power BI service admin settings in your tenant. For more
information, see Enable service principal authentication for read-only
admin APIs.
So you should enable the Power BI service admin settings.
Besides, you should note these tips and make sure that you did not break
Related
This relates to the documentation that is available at the link below.
https://learn.microsoft.com/en-us/azure/devops/migrate/migration-overview?view=azure-devops
What would be the minimum role for a user to complete the migration successfully and without any permissions issues? That is my question.
For example, the user must have the what kind of necessary roles and permissions on both the Azure Devops server and the Azure Devops Services.
According to the Data Migration Utility Guide, the user who uses this tool must possess the following:
SQL Server's TFSEXECROLE role, and
Access rights to the TFS collection and configuration databases.
My understanding for example :-
Azure DevOps Server:
If we add the user to the Team Foundation Administrators group on the Azure DevOps Server, does the role fulfill.
Azure Devops Services: If we assign the same user who performs migration as an Azure DevOps Administrator mention in the below image on the Azure devops services, does the below role fulfill.
"Azure Devops Administrator"
Also, it would be useful if you could specify the maximum size limit of the. Dacpac backup file that the Data Migration Tool supports (i.e. the maximum size of the project collection backup) in order for the migration to go properly.
What permissions does the same user that runs the data migration tool need in SQL server to perform the command SqlPackage.exe?
I would thank you in advance for the help. It would help us to understand the better usage of the Data Migration Tool.
Many Thanks..!
Best Regards
we have azure devops pipelines to build and deploy various projects.
Rccently, we wanted to use the "azureblog file copy" pipeline to copy some files to a blob storage.
This needs write access to the storage account over in azure.
Our administrator says that the pipeline runs as whoever manually runs the pipeline. If this is true, we would have to give all devs and users read/write access to the blog storage, which would be crazy.
I assume he is wrong, and that pipelines run as a specific designated user no matter how they were kicked off. The question is, how to find out what this user is for a given pipeine?
The "edit pipeline" has a security tab near the top, adn this lists a but of "Azure Devops groups", which are presumably groups who have the ability to run the pipelines.
But where is the pipeline user defined?
which user do Azure devops pipelines run as?
It depends on the context in which you are discussing the question.
If you mean inside a pure DevOps service, then I can tell you that the user that the pipeline runs on is not the one who triggers the pipeline (which is the case with native DevOps services by default, unless you install some weird extension or have a problem with the pipeline special design), but this identity:
<Project Name> Build Service Account
'run as someone' is just a property of pipeline run. Pipeline run as 'Build Service Account'(On the DevOps side), If you need a pipeline to download or upload an artifact, you can clearly feel this. If the account mentioned above has no permission, you can't do anything.
If you mean the user's operations based on the Azure side, then I can tell you that for native DevOps service, the 'user' that the pipeline performs operations on the Azure side is not the person who triggers the pipeline. The pipeline of DevOps service consists of multiple tasks, and tasks generally interact with other services through service connection (you can find this in Project settings).
There are many types of service connections. When interacting with services in Azure, this type is generally used:
Azure Resource Manager -> Service principal
When you create a service connection of this type on the DevOps side, Azure will also create an AAD app related to this service connection, and this ADD app corresponds to a service principal in Azure. In Azure, permissions are assigned based on service principals or users, and your DevOps pipeline's operations to Azure are based on this service principal and have nothing to do with anything else in DevOps. On the Azure side, this service principal can be considered as an Azure-side 'avatar' of the tasks of the DevOps pipeline.
If you are interacting with Azure through pure code/pure script, then please follow the logic of the script/code.
Our administrator says that the pipeline runs as whoever manually runs
the pipeline. If this is true, we would have to give all devs and
users read/write access to the blog storage, which would be crazy.
For native DevOps service, of course not. Unless this pipeline has a special design.
I believe the pipeline runs as the "agent". Who the "agent user" is will depend on, first, whether you've chosen a "Microsoft-hosted" or "self-hosted" agent to run your pipeline.
When running pipelines in Azure DevOps that are directly working with Azure Resources you need an Azure Resource Manager service connection. The credentials used to make the service connection are the credentials the pipeline will use when it runs.
You can have your administrator provide you with an Azure AD account that has the permissions you need and then use that Azure AD account to create the service connection for the pipeline. Once you have created the service connection you can use the ResourceID of that connection in place of you azureSubscription.
Here is the link to the Microsoft documentation on creating a service connection.
Here is the link to the Microsoft documentation on the Azure file copy task. To verify you can use the service connection in place of the azureSubscription.
Was working on az ml cli v2 to deploy real-time endpoint with command az ml online-deployment through Azure pipeline. had double confirmed that the service connection used in this pipeline task had added the permissions below in Azure Portal but still showing the same error.
ERROR: Error with code: You don't have permission to alter this storage account. Ensure that you have been assigned both Storage Blob Data Reader and Storage Blob Data Contributor roles.
Using the same service connection, we are able to perform the creation of online endpoint with az ml online-endpoint create in the same and other workspaces.
Issue was resolved. I did not change anything in the service principal and running it on second day using same yml got through the issue. I guess there might be some propagation issue, but longer than usual.
I am junior admin managing ADO 2020 on Prem . We have a developer who is able to create a work item in a board under a collection/project when logged in using ADO .
The developer is trying to automate work item creation using Power Automate . He is giving the correct information in Power Automate at the required fields. When trying to create a work item, he gets this error
Details: {"$id":"1","innerException":null,"message":"TF400813: The user '157adfsd-912f-4244-xxxx-b45fcasda\\firstname.lastname#domainname.com' is not authorized to access this resource.","typeName":"Microsoft.TeamFoundation.Framework.Server.UnauthorizedRequestException, Microsoft.TeamFoundation.Framework.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=acdb03fxxxxxxsdfdsdse","typeKey":"UnauthorizedRequestException","errorCode":0,"eventId":3000}
Question : From ADO 2020 side, is there any kind of permission I need to provide to the developer ? I am not 100 % sure why we get this error as the developer is manually able to create a work item.
To my understanding, Power Automate connects to Azure DevOps Services (that is, the cloud-hosted version of Azure DevOps) via OAuth, and when you are creating Power Automate flow for Azure DevOps, the tool tip when selecting an organization tells you to make sure that the Third Party application access via OAuth is enabled.
I don't think that the OAuth 2.0 authentication (https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops) is available for the on-premises version, so you might be out of luck there.
There is an answer to similar question in Power Automate-forum suggesting that the integration might be possible via installing an on-prem data gateway, but wouldn't really know if it's feasible.
https://powerusers.microsoft.com/t5/Connecting-To-Data/Power-Automate-with-Azure-Devops-Server-On-Premise/td-p/658618
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: