Managed identity and service principal support for Azure DevOps now in General Availability (GA)
After announcing the release of Managed Identity and Service Principal support in public preview last March, we were overcome by the positive response many of you had. We’re grateful to those who have taken the time to implement a managed identity within your apps and tools. With your help, we’ve collected valuable feature feedback and resolved some hidden bugs to improve the overall performance of this feature, bringing us to today, when we’re happy to announce that the feature is now in General Availability (GA).
Some notable GA user-facing updates worth calling out:
1. Set object-level permissions on service principals and managed identities across the site:
We’ve scoured the site to look for every dropdown where it makes sense to include service principals. They have now been added to many object-level permissions dialogs across the platform, allowing you to set specific permissions for service principals in objects, such as Agent Pools, Feeds, Packages, Service Connections, and more.
2. Extended capabilities for service principals and managed identities in the Boards space:
Service principals are now a little more powerful in Boards! Service principal support in Boards has been extended in the following places:
- Assign To field of a work item,
- Queries,
- Boards’ configuration pages, including for swimlane and style rules,
- Boards’ cards,
- Process rules and custom identities
3. Service principals and managed identities are blocked from using Azure DevOps OAuth:
To reduce confusion on how service principals might be used, we have disabled any implementation of service principals in Azure DevOps OAuth flows, as they only pertain to the Microsoft Identity platform, and not Azure DevOps’s OAuth platform.
We continue to welcome any new feedback you have on how we can improve this feature. But we hope the bug fixes and feature improvements we’ve made over these past few months will mean even more of you will explore implementing it more broadly within your organizations. Docs have also been clarified to address questions that have come up since public preview.
And as always, the comments section and the Developer Community remain open for you to share any thoughts and concerns you’d like us to hear!
Light
Dark
7 comments
Are you able to provide any information on if this change is what caused VS 2012 and other similar products to lose the ability to connect to Azure DevOps Services? We’ve been receiving TF30063 and similar errors for about a week, and I see many other people having similar issues beginning this month. We’re currently trapped in VS 2012 for a portion of our development so this has crippled us.
It’s very frustrating since a substantial number of Azure DevOps Services users have been left scrambling for a solution with no advance notice of a breaking change or proper availability of testing windows. This is very similar to the recent TLS issue, but this time MS has not been prompt with providing assistance.
https://developercommunity.visualstudio.com/t/TF30063-and-associated-errors-since-920/10473760
https://developercommunity.visualstudio.com/t/Login-from-AX2012-R3-Version-Control-not/10461669
Hi Ben, let me have someone look into this and get back to you. Thanks for sharing
Thank you Angel for this great post. Can you share if there is an option to use system/user-managed identity to connect to Azure repos to perform git commands (clone code, pull,push…). As I see now in service connection to Azure Repos we can use only following Authentication methods: Token Based Authentication and Basic Authentication.
Hi Lior, the following FAQ question might be of help to you: https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/service-principal-managed-identity?view=azure-devops#q-can-i-use-a-service-principal-to-do-git-operations-like-clone-a-repo
Hello
Do you plan to support this within Azure Pipeline Agents? This feature is awesome but we still need a PAT for using Azure Pipeline Agents, so we are still blocked by that, this is awesome but not enough.
Hi Jorge, what do you mean with support within Azure Pipeline agents? From agent v3.227.1 you can use an App Registration or AAD user to register the agent, see release notes and docs.
I think it is great that we can stop relying on personal accounts (and their tokens) and intead use technical accounts. However, the implementation is not sufficient, since one cannot simply use the client secret, but needs to create an access token with it, which is only valid for a short amount of time. I get the idea for custom built applications, but I need to use those credentials to connect our Azure Repos to GitOps tools like Terraform Cloud or FluxCD. Any plans to also allow this? Alternatively generating a PAT for managed identities could be an option.