Fixing workload identity federation conversion failures in Azure DevOps

Introduction

Microsoft released into public preview in Q4 last year, workload identity federation service connections for Azure DevOps. This was very welcomed, as it greatly improves your security posture by using short-lived authentication tokens with no persistent secret to manage.

For the most part, all my Service Principals to workload identity conversions in Azure DevOps for customers and internal service connections have been smooth sailing.

However, I recently hit a few errors in a row with the same message cropping up:

Google came up with a few solutions, however, I wanted to specifically put together a quick guide on how to resolve this if you get it in Azure DevOps. We’ll have to manually create the federated identity in Microsoft Entra.

Here’s the error I was getting with a few conversions:

Manual creation – the fix

• Pre-reqs: PIM up to Application administration role in Microsoft Entra

The ‘try again’ button seemingly didn’t do anything, so I set on trying to fix this by manually creating the federated identity directly to the Entra app registration.

You’ll notice when the workload identity conversion fails you get additional the authentication conversion details to help assist going down this manual route, highlighted like so (hidden sensitive values):

Using these details we can begin to create the federated identity manually.

Firstly, create a .json file on your local machine, and copy the details in from the code block I have below , amending the values to match that from the authentication conversion box seen above:

{
 "name": "__resourceId__",
 "issuer": "https://vstoken.dev.azure.com/__ISSUER__",
 "subject": "sc://ADO_ORG/ADO_PROJECT/SPN_NAME",
 "description": "Federation for Service Connection for spn-ado-example-prod",
 "audiences": [
     "api://AzureADTokenExchange"
 ]
}

The resourceId can be found in the URL of the service connection if you need this as the name.

https://dev.azure.com/YOURADOORG/ADOPROJECT/_settings/adminservices?resourceId=here

Once saved locally we’re now able to create the federation identity manually using Azure CLI.

We’ll need to grab the applicationId from the Entra app of the SPN we’re looking to convert.

az login
az ad app federated-credential create --id APP-ID --parameters "file.json"

Lastly, we need to go back into Azure DevOps service connections on the ADO project, locate and open the Service connection that previously had failed.

Now we’re able to click the “try again” button and then edit the connection to ‘verify & save’.

This will complete the workload identity conversion to Azure DevOps manually.

And that’s it!

It’s been mostly plain sailing for me with workload identity conversions but a few have thrown odd errors. A much needed security enhancement that is welcomed.

Let me know in the comments if you had this issue.