Getting error about misconfigured federated credentials in task using WIF

[jcksonhe]

Hi team,

In need of some help setting up a release pipeline using the Power Platform Import Solution task using WIF

I've followed the instructions here: https://github.com/microsoft/powerplatform-build-tools/discussions/884 But just in case I missed a step, I'll sum up what I've done:

1. Created an app registration, noting the app & tenant IDs
2. Created a Power Platform service connection using WIF, using the noted app ID for the service principal ID (and tenant ID for the tenant ID):
3. On the app registration, add federated credentials following the discussion above:
   • Issuer: https://vstoken.dev.azure.com/{OrgId}
   • Subject Identifier: sc://{OrgName}/{ProjectName}/{ServiceConnectionName}

However, in my release pipeline using the "Power Platform Import Solution" task pointing to this service connection, I get the following error:

I've quadruple-checked the Issuer and Subject Identifier - They are definitely correct. Did I miss a step or configure something else incorrectly? Any help would be greatly appreciated.

Thanks!

[devkeydet]

Nothing obvious jumps out at me. Have you reviewed this discussion? https://github.com/microsoft/powerplatform-build-tools/discussions/884

[jcksonhe]

Nothing obvious jumps out at me. Have you reviewed this discussion? #884

Hey @devkeydet. Yes, I have reviewed that discussion - it's the same one I followed above. Are there any alternatives aside from using passwords in the task or client secrets through the service connection? I saw Managed Identity as an option in the Power Platform service connection, but we can't provide any authentication details?

[petrochuk]

For Managed Identity pac cli essentially uses DefaultAzureCredential which goes through 8 step process to discover identity we can use.

[jcksonhe]

For Managed Identity pac cli essentially uses DefaultAzureCredential which goes through 8 step process to discover identity we can use.

Thanks! Will try this.

[tehcrashxor]

Hmm. @jcksonhe, while the red error explains what those values should be, there should also be error text (probably not highlighted in red) in the output below the line in your screenshot.

As an example, one our test pipelines with intentionally misconfigured federation the yellow highlighted line has the full error message coming from AAD / Entra ID (though the lack of word wrap makes getting that all in a screenshot annoying as it's a long single line).

What does that text say?

---

The fact that the issuer text in the error you shared is being replaced by the [***] log redaction makes that annoying to double check if you have the correct value. Note that the OrgID value there is not your CRM/PowerPlatform Org ID, but the Azure DevOps OrdID your pipeline is in. Could the perhaps be the issue?

[jcksonhe]

@tehcrashxor Thanks for looking at this. I got the OrgId using this GET call, replacing OrgName with the same name in ADO: https://dev.azure.com/_apis/resourceAreas/79134C72-4A58-4B42-976C-04E7115F32BF?accountName={OrgName}&api-version=5.0-preview.1

As for the error, I have the exact message as you

[tehcrashxor]

@jcksonhe, unfortunately the important bit of that line requires scrolling further to the right. AADSTS700211 appears to be the error code for having a wrong value for the issuer. (AADSTS700213 - error for wrong subject, AADSTS70025 - error for no federated credentials on the SPN)

[tehcrashxor]

Making that API call for our test org returns a different GUID than that test org's Org ID.

Since the value is being redacted in the logs, you should also be able to find that value from making a Service Connection for Azure Resource Manager. Example:

Create a new service connection, selecting Azure Resource Manager

Choose Workload Identity Federation (manual), and hit "Next"

Fill out any name and click "Next"

Copy the Issuer field provided on that next page:

Then feel free to delete the draft ARM service connection.

We would like to make our own Service Connection behave like the Azure Resource Manager one does, providing those details at creation time. Unfortunately, that multi-stage behavior and filling in values like that is not possible Service Connections provided by an Extension as ours is; ARM's service connection is built into ADO, where they have much more flexibility to provide those details.

[jcksonhe]

Thanks @tehcrashxor , will try this out and report back

[jcksonhe]

Making that API call for our test org returns a different GUID than that test org's Org ID.

Since the value is being redacted in the logs, you should also be able to find that value from making a Service Connection for Azure Resource Manager. Example:

Create a new service connection, selecting Azure Resource Manager

Choose Workload Identity Federation (manual), and hit "Next"

Fill out any name and click "Next"

Copy the Issuer field provided on that next page:

Then feel free to delete the draft ARM service connection.

We would like to make our own Service Connection behave like the Azure Resource Manager one does, providing those details at creation time. Unfortunately, that multi-stage behavior and filling in values like that is not possible Service Connections provided by an Extension as ours is; ARM's service connection is built into ADO, where they have much more flexibility to provide those details.

This worked!! Thank you so much @tehcrashxor!!