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
Related
I have an Azure DevOps server on-premises and I have written a small application that simply queries its API to get information from the Azure server. There is no authentication at the user level, since the application only displays information and does not POST/PUT/DELETE.
To query the API, I have used my PAT (personal access token), but this is not ideal. I have read that on the cloud version of Azure, you can just register the application to do it, but I have not found the same functionality for the on-premises version.
Am I missing something? Is the only alternative creating a technical user on the LDAP and get a PAT for it?
Is the only alternative creating a technical user on the LDAP and get
a PAT for it?
Yes, you are right.
Authorize access to REST APIs with OAuth 2.0
So 'App auth' is only supported in Azure DevOps Services (VSTS), not supported in Azure DevOps server (TFS).
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
I am creating a logic app that will trigger when a form request is submitted.
The MS Form connector requires me to sign in. This is acceptable during development, but we have a lot of logic apps and so use DevOps to automate deployment.
With the current connector, after deployment we still have to:
manually open the logic app in the portal.
connect using authorized credentials.
save the logic app.
This manual process completely defeats the point of using DevOps with Logic Apps.
Its a similar issue when using the Outlook connector.
Is there a way to supply server principal credentials to these connectors, so that they are correct at deployment time and require no manual intervention?
It seems that it's not supported to login on MS Forms connector with service principal. Connectors that can use service principal authentication will have "Connect with Service Principal" option, like Azure Data explorer. You can give your voice on this feedback to promote this feature.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors etc, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
Here is a ticket you can refer to.
I would like to find out what the best practices are for managing developers' access to a sub-set of resources on a client's subscription?
I've searched Google and the Azure documentation looking for definitive answers, but I have yet to come across an article that puts it all together. Because Azure is still developing so rapidly I often find it difficult to determine whether a particular article may still be relevant.
To sum up our situation:
I've been tasked with researching and implementing the Azure infrastructure for a web site our company is developing for a client. At the moment our manager and I have access to the client's entire subscription on the Azure Portal by means of the Service Administrator's credentials, even though we're managing only:
Azure Cloud Service running a Web-Role (2-instances with Production and Staging environments).
Azure SQL Database.
Azure Blob Storage for deployments, diagnostics etc.
We're now moving into a phase where more of the developers in the team will require access to perform maintenance type tasks such as performing a VIP swap, retrieving diagnostic info etc.
What is the proper way to manage developer's access on such a project?
The approach I've taken was to implement Role Based Access Control (https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/)
Move 1, 2, and 3 above into a new Resource Group according to http://blog.kloud.com.au/2015/03/24/moving-resources-between-azure-resource-groups/
Creating a new User Group for our company, say "GroupXYZ".
Adding the "GroupXYZ" to the Contributor role.
Adding the particular developer's company accounts to "GroupXYZ"
Motivation for taking the role-based approach
From what I understand giving everyone access as a Co-Administrator would mean that they have full access to every subscription in the portal.
Account-based authentication is preferable to certificate-based authentication due to the complexity added by managing the certificates.
What caused me to question my approach was the fact that I could not perform a VIP swap against the Cloud Service using PowerShell; I received an error message stating that a certificate could not be found.
Do such role-based accounts only have access to Azure by means of the Resource Manager Commandlets?
I had to switch PowerShell to the Azure Service Manager (ASM) Mode before having access to the Move-AzureDeployment commandlet.
Something else I'm not sure of is whether or not Visual Studio will have access to those resources (in the Resource Group) when using Role Based Access Control.
When you apply RBAC to Azure as you have or just in general, give access to an account via RBAC, then those accounts can only access Azure via the Azure Resource Manager APIs, whether that's PowerShell, REST or VS.
VS 2015 can access Azure resources via RBAC when using the 2.7 SDK. VS 2013 will have support for it soon.
I am trying to build a web part to be hosted on SharePoint online (part of Office 365). I want to use Entity Framework to connect to a DB in SQL Azure. Is this even possible? I tried deploying one solution, but I get very unhelpful error saying "Web Part Error: Sandboxed code execution request failed.".
Anyone get this combination working?
I found out that this is not possible. The reason is due to the restricted permissions in the Sandbox and cannot use a proxy to bypass that. The only way to access SQL Azure from within SharePoint online in Office 365 is via a web service exposing operations on the entities residing in SQL Azure. I am currently investigating that approach and once I have more info, I can update this answer.
Update 7/27: Using a web service serving SQL Azure data, we can integrate SQL Azure with SharePoint. The component in SharePoint that enables this integration is called 'Business Connectivity Services'.
More can be found here: http://blogs.msdn.com/b/donovanf/archive/2012/06/25/office-365-o365-business-connectivity-services-bcs-hands-on-lab-wiring-up-o365-bcs-to-a-windows-azure-service-for-office-2010-and-sharepoint-online-solutions.aspx