I'm having a error when try connect power automate with Azure DevOps. I have two ways to login, personal and business account.
I need to use the business account because it contains the automate license.
When I use my personal account, I can acess the projects.
But when i use my business account, the power automate show me a error.
In Azure Devops I'm using my business account and I'm in all projects and permissions.
I enabled auth in Azure Devops.
And my access level is basic
Related
we use a devops artifact feed to store our packed/shaded java binaries inside a private project. Now we would like to allow access to certain artifacts for externals.
We will promote these artifacts to a custom view (#public-releases) and want to allow access to this view for certain customers only (s.t. they can use it in their automation).
Is it possible to have some kind of service-account/service-principal to assign read-permissions in devops?
I know it the other way round (give devops access to azure ressources via service connections), but now I want to permit access to Devops Feeds.
How would I create such a User? We have azure AD connected, so maybe that is an option?
Is it possible to have some kind of service-account/service-principal
to assign read-permissions in devops?
No, no such design.
Service principal of Azure Active Directory concept can not be managed as an account in DevOps side(DevOps doesn't have such account type, only internal service principal, no AAD service principal).
As you know, service principal of AAD can manage access to services in azure portal. This is the usual usage. Another usage is Authenticate with Azure Active Directory (Azure AD) tokens, this approach can be used to manage PAT of DevOps, but anyway you end up needing to access the feed based on a legitimate account under the DevOps concept.
Is it possible to have a service principal account trigger a build pipeline? I have a CMS that whenever a document is published it fires of an event/webhook that's calls an Azure Function. The function then calls Azure DevOps using the API to trigger the correct build pipeline. Up until now we have relied on personal access tokens (PAT) from a "lucky" team member, but obviously that isn't an ideal solution. If the PAT expires or the team member leaves our pipeline breaks down. I was hoping to use the PAT Lifecycle Management API* to generate a PAT on the fly, but as the documentation states; "On-behalf-of application" solutions (such as the “client credential” flow) and any authentication flow that does not issue an Azure AD access token is not valid for use with this API".
This seems like a fairly common scenario, having an external dependency kicking of a build pipleline, so how should I go about doing this without using person-dependent tokens?
https://learn.microsoft.com/nb-no/azure/devops/organizations/accounts/manage-personal-access-tokens-via-api?view=azure-devops
Externally trigger an Azure DevOps Build using a Sevice Principal account
I am afraid it it impossible to use REST API to trigger an Azure DevOps Build using a Sevice Principal account.
That because the Azure DevOps API doesn't support non-interactive service access via service principals.
You could get the info from the document Choose the right authentication mechanism：
After a couple companies merge, we had to build up an AZ DevOps solution from scratch for the new business entity. Unfortunately, at that time we added some users from various companies under their original email addresses (reason: reuse of their VS subscriptions).
Now we need to migrate these users in Azure DevOps from their old bill.smith#oldcompany.com to their new bill.smith#newcompany.com without losing their work and settings. Afterwards the users should be able to log in with their new emails and see everything as if they would log in with their old addresses.
Any ideas how to solve this problem?
You need to open a support case and they can help you out. You get a excel file to map users between the domains and they can map them over in one go.
jessehouwing is right, if you want to migrate data to new Azure DevOps users, you need submit a support ticket here.
But there are something you need pay attention and get ready first:
Do not add them (bill.smith#newcompany.com) to Azure DevOps Service or let them logon to Azure DevOps Service. At this point
Azure DevOps Service support needs to migrate/transfer the users.
Provide a mapping list of users (old user > new user) to Azure DevOps
Service Support.
Azure DevOps Service will transfer identities to the new users. This should add the new account to Azure DevOps Service, assign work items to the new account, assign the Azure DevOps Service license to the new account , and remove the old account from Azure DevOps Service.
looking at "Authorize access to REST APIs with OAuth 2.0" at https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops
An Azure DevOps organization is connected to an Azure Active Directory tenant
-> let's call it 'devops-ad-tenant'.
A user has an Active Directory Home Tenant
-> let's call it 'user-ad-home-tenant'.
A user can be a guest user withing another Active Directory Tenant
-> let's call it 'user-ad-guest-tenant'.
If the 'devops-ad-tenant' is equal to the 'user-ad-home-tenant', everything works out fine.
If the 'devops-ad-tenant' is equal to the 'user-ad-guest-tenant', the OAuth flow succeeds, but the flow happens within the context of the 'user-ad-home-tenant' and this user is from a Azure DevOps perspective not the user from 'user-ad-guest-tenant'.
I am having trouble to use something like a "domain_hint" when initiating the OAuth flow.
Any thoughts?
This behavior of get the token is used for the home directory is by design since the customer may be as guest for multiple Azure Active Directories. And as the document you shared for the Azure DevOps OAuth authentication, currently there is no such option to choose which directory for the usage of token acquired.
If you want Azure DevOps support this feature, you can submit the feedback from Develop Community - Azure DevOps.
I managed to get along with a work around...
My application uses an Azure AD multi-tenant appRegistration for authentication.
When the user logs in at my application, the OAuth flow for Azure DevOps is started.
To set the Azure AD tenant for the OAuth flow for the Azure DevOps organization
use a clean browser session, no cookies etc.
log into https://aex.dev.azure.com and select the Azure AD tenant 'user-ad-guest-tenant' for Azure DevOps organization
duplicate that tab
enter the url for my application
the OAuth flow happens within the context of 'user-ad-guest-tenant'
this is really inconvenient... but a work around... besides I am still investigating why this is working...
I was playing around to learn the feature and concept on Azure DevOps services.
And I created one Azure DevOps Organization using my MSA account and connected it to my Azure Active Directory (as I have a pay-as-you-go subscription using my MSA account).
I then disconnected it from Azure Active Directory so it (forced) logged me out of the Azure DevOps portal. I was thinking that I will disconnect and connect it back to AAD. But apparently that's not how it works... and I found out in a very rude way.
After that I was unable to login to the Azure DevOps service portal using my MSA ID. And here is the error page:
I was able to somehow get over the issue by creating a new org using the organization list link provided on the error page.
But now my question is, I do see my old DevOps Organization on Azure
DevOps Service portal which I am unable to access. Its sort of orphaned Org and just hanging there. Now how do I get rid of
it or delete it?
what is happening is that azure devops is not able to sync up with your AAD. The reason it is showing "not authorized error" is because it can't identify whether the same tenant is trying to connect(when you're logging in) to the project and the project is in the AAD parallely, so that is creating the miscommunication between your tenant, AAD and devops organisation.
Sign out, and then open your browser in a private session and sign in to your organization with your Azure AD, MSA or work credentials.