[BUG]: Federated access is not working (or not getting expected env variables)

[oasaleh]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

AzurePowerShell

Task version

5

Issue Description

I have two tenants: A and B. Pipeline is in tenant B, while my SQL Server is in tenant A. I have a service connection that's known to work with other resources (a Blob storage account in Tenant A that's being access by other pipelines in the same pool using the same image.)

I am trying to run the following in my pipeline.

variables:
  labConn: "Server=tcp:my-sql-server.database.windows.net;Initial Catalog=my-db-dev;Authentication=Active Directory Default;Encrypt=True;"

steps:
  - task: AzurePowerShell@5
    displayName: "Run EF bundles - DEV - Azure PowerShell"
    inputs:
      azureSubscription: "nameOfMyServiceConnection"
      pwsh: true
      azurePowerShellVersion: "LatestVersion"
      failOnStandardError: true
      scriptType: "InlineScript"
      workingDirectory: $(Pipeline.Workspace)/ci/drop/ef-bundles
      Inline: |
        ./lab-db.exe      --connection "$(labConn)"

I get the following error:

Microsoft.Data.SqlClient.SqlException (0x80131904): Login failed for user '<token-identified principal>'. The server is not currently configured to accept this token.

I already gave the MI in Tenant A that's connected to the service connection access to the SQL DB.

When I dump env variables, I get the following:

AZURESUBSCRIPTION_CLIENT_ID=<MI's object ID in Tenant A>
AZURESUBSCRIPTION_SERVICE_CONNECTION_ID=<A GUID>
AZURESUBSCRIPTION_TENANT_ID=<Tenant A ID>

To my understanding, these are not the expected names for env variables.
Also, shouldn't there be a AZURE_FEDERATED_TOKEN_FILE as well?

Thanks!

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

Microsoft Windows Server 2022

Relevant log output

Login failed for user '<token-identified principal>'. The server is not currently configured to accept this token.

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

[v-schhabra]

Hi @oasaleh
Could you please let us know if it works for you earlier you are trying it for the first time?

[oasaleh]

In this same context of work, I can't tell because I've never had to run it like that (an exe that requires MI within a PS session.)

However, what has been working (and still is) is to do something like the following.

New-AzStorageContext -StorageAccountName $StorageAccountName -UseConnectedAccount -ErrorAction Stop

This will create a storage context using the federated identity to reach a storage account in a different tenant than the pipeline's.

If I do the following, it will sign in the pipeline using its managed identity to reach resources within the same tenant.

Connect-AzAccount -Identity -ErrorAction Stop -WarningAction SilentlyContinue
New-AzStorageContext -StorageAccountName $StorageAccountName -UseConnectedAccount -ErrorAction Stop

I understand the behavior above. AzurePowerShell@5 already connects and sets the context for whatever Azure Subscription the service connection is pointing to. Hence, just creating a storage account context works. Re-connecting however, uses the immediately available creds, which is the pipeline's service principal. Then re-creating the storage context uses the new(er) token.

Now, my issue is a bit different since Entity Framework bundles rely on a separate SQL driver. To my understanding, EF looks for specific env variables to be able to use the managed identity.

I was able to overcome my problem by doing the following, but it's a "hack" and I think it should be addressed.

1. Instead of using AzurePowerShell@5, I used AzureCLI@2. This is because AzureCLI@2 writes the token as an env variable called idToken when addSpnToEnvironment is set to true.
2. Write that token to a file with extension .jwt.
3. Create a new env variable called AZURE_FEDERATED_TOKEN_FILE that points to the file containing the token.
4. Map the following env variables to new, differently named env variables like so.

$env:AZURE_CLIENT_ID = $env:servicePrincipalId
$env:AZURE_TENANT_ID = $env:tenantId

Note that AzurePowerShell@5 writes the client ID and tenant ID as env variables but not as AZURE_*. Instead, it writes them as AZURESUBSCRIPTION_*. But again, this is not the issue. The issue is getting the token.

So, the code eventually looked something like this.

$tokenPath = Join-Path $env:AGENT_TEMPDIRECTORY 'ado_wif.jwt'
Set-Content -Path $tokenPath -Value $env:idToken -Encoding ascii -NoNewline

$env:AZURE_CLIENT_ID            = $env:servicePrincipalId
$env:AZURE_TENANT_ID            = $env:tenantId
$env:AZURE_FEDERATED_TOKEN_FILE = $tokenPath

Now, when I run my Entity Framework bundles, they work as expected.

It's odd to me that AzurePowerShell@5 writes env variables under different names than what's expected in the .NET ecosystem. Finally, it would be nice to create the file and to set AZURE_FEDERATED_TOKEN_FILE to point to the file's location so we can use that file since the token is not written as an env variable.

[v-vikjadhav]

We have tried to reproduce the issue with YAML template you have shared, but not able to get that error. Could you please share the repro steps for the mentioned issue?

[v-vikjadhav]

Hi @oasaleh Thank you for your detailed feedback and for sharing your workaround involving AzureCLI@2 to enable Entity Framework bundles to authenticate using Workload Identity Federation (WIF). We appreciate your effort in identifying the gap and proposing a solution.

We specifically discussed the idea of having AzurePowerShell@5 expose the federated token via environment variables such as AZURE_FEDERATED_TOKEN_FILE to support .NET SDK scenarios. Our engineering manager has confirmed that persisting the federated token to disk (as required for AZURE_FEDERATED_TOKEN_FILE) is not secure by design.

This approach introduces several risks:

Token leakage: Writing tokens to disk increases the risk of unauthorized access.
Encouraged reuse: Persisted tokens may be reused beyond their intended scope or lifetime, leading to authentication failures due to token expiration or context mismatch.

[oasaleh]

@v-vikjadhav - I agree writing the token to disk is not optimal but what is the official solution/proposal to support .NET SDK scenarios?

[v-vikjadhav]

Hi @oasaleh You can use the azurepipelinescredentials for azure pipelines to authenticate securely using Workload Identity Federation, without writing tokens to disk.

https://devblogs.microsoft.com/azure-sdk/improve-security-posture-in-azure-service-connections-with-azurepipelinescredential/

[v-vikjadhav]

Hi @oasaleh Does this issue resolved for you after usage of azurepipelinescredentials? Could you please provide update on this.

[v-vikjadhav]

@oasaleh Could you please provide update on this issue. is it resolved or it still persist for you?

[v-vikjadhav]

Resolving this issue as resolution steps shared but we have not received further updates from customer after multiple follow ups.