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 you are looking to to fix in Azure DevOps:

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

Fill out the rest of the json file with the details from within the authentication conversion box. Once saved, on your local machine, you’ll now able to create the federation identity manually using Azure CLI passing this json file through as the metadata to fix the conversion.

Next, you’ll need to grab the applicationId from the Entra app of the Service Principal Name you’re looking to manually convert. You can usually find this by searching for your Azure DevOps service connection name in the Azure Portal search box or via Entra users. Run the below Azure CLI:

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

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

Now you should be able to click the “try again” button and then edit the connection to ‘verify & save’ successfully finishing the manual conversion.

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.