Deployment Stage Fails with DefaultAzureCredential Error – Authentication Succeeds

[Shiva3]

I’m a DevOps engineer automating CI/CD deployments to a Microsoft Fabric Dev/Test workspace using Azure DevOps. We are using a service principal (service account) for authentication.

✅ Authentication completes successfully, but during the deployment stage, we receive the following error:

DefaultAzureCredential failed to retrieve a token from the included credentials.

This happens when the deployment script (deploy.py) runs, even though the service principal is authenticated earlier in the pipeline.

---

❓ What We Need

1. Why would DefaultAzureCredential fail during deployment even after successful authentication?
2. Are there any Fabric-specific configurations or SDK requirements we should be aware of?
3. Can you provide a working example or best practices for deploying to Fabric using Azure DevOps?

---

🛠️ Our Goal

To build a secure, automated Azure DevOps pipeline that:

• Deploys artifacts to a Fabric workspace
• Works reliably across environments (Dev, Test, Prod)

[burakkaragoz · Accepted solution]

Hi @Shiva3 ,

Great question—this is a common stumbling block when automating Fabric deployments with Azure DevOps and service principals. Here’s a detailed breakdown and best practices:

---

1. Why does DefaultAzureCredential fail during deployment even after successful authentication?

• Different Contexts in Pipeline:
  Authentication might succeed during the initial stages (e.g., in Azure DevOps tasks), but when the deployment script (deploy.py) runs, it could be executed in a different context or environment variable scope. The DefaultAzureCredential flow checks multiple credential sources and may not pick up your service principal as expected during the script run.

• Missing Environment Variables:
  Ensure that all required environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET) are available in the context where deploy.py executes—not just in the pipeline, but for any subprocesses as well.

• Token Caching/Expiration:
  If there’s a delay or context switch, the acquired token may expire or not be forwarded properly between steps.

• User vs. Service Principal Permissions:
  Sometimes, the initial authentication uses a user identity, but the deploy script is forced to use a service principal, which may lack certain permissions on the Fabric workspace or resources.

---

2. Fabric-Specific Configurations or SDK Requirements

• Required Permissions:
  Double-check that your service principal has all the necessary permissions on the Fabric workspace (Contributor or higher, Data Admin roles if needed).

• Supported SDK/CLI:
  Make sure you’re using the latest Azure SDKs compatible with Microsoft Fabric, and that your service principal is granted necessary RBAC roles both in Azure and in Fabric itself.

• Service Connection in Azure DevOps:
  If using an Azure Resource Manager service connection, verify that it’s set to use the correct service principal and that it’s available to all pipeline tasks and scripts.

---

3. Working Example / Best Practice

Best Practice:
Set the required environment variables explicitly in the pipeline before running your Python deployment script, so DefaultAzureCredential always picks up the correct credentials.

Example YAML snippet:

YAML

- task: Bash@3
  env:
    AZURE_CLIENT_ID: $(servicePrincipalId)
    AZURE_TENANT_ID: $(tenantId)
    AZURE_CLIENT_SECRET: $(servicePrincipalKey)
  inputs:
    targetType: 'inline'
    script: |
      python deploy.py

Python (deploy.py) snippet:

Python

from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient

credential = DefaultAzureCredential()
client = ResourceManagementClient(credential, "<subscription_id>")
# ... your deployment logic ...

• Make sure the pipeline variables (servicePrincipalId, tenantId, servicePrincipalKey) are populated from your Azure DevOps service connection.

Extra Tips:

• If you’re using managed identities (e.g., Microsoft-hosted agent with Managed Identity enabled), ensure the identity has permissions in both Azure and Fabric.
• Use az login with service principal before script runs to confirm credentials are valid (for debugging).
• Log the current principal in your script to be sure which identity is being used.

---

Let me know if you need a full working pipeline example or if you hit any other errors—happy to help you troubleshoot further!

[Shiva3 · Accepted solution]

The issue has been resolved by adding an additional step—logging into Azure CLI using a service account to complete the DefaultAzureCredential authentication flow. Multi-Factor Authentication (MFA) has been disabled for this service account, and currently, the CI/CD deployment is functioning as expected.

Concern:

However, I’m concerned about the upcoming change:

⚠️ Starting July 1, 2025, MFA will be gradually enforced for Azure public cloud. Authentication using username and password via the command line will no longer be supported with MFA. Consider switching to a supported authentication method.
More details

If MFA becomes mandatory, CLI login using the current service account setup may no longer work, potentially disrupting our deployment pipeline.

[burakkaragoz · Accepted solution]

Hi @Shiva3 ,

Great question—this is a common stumbling block when automating Fabric deployments with Azure DevOps and service principals. Here’s a detailed breakdown and best practices:

---

1. Why does DefaultAzureCredential fail during deployment even after successful authentication?

• Different Contexts in Pipeline:
  Authentication might succeed during the initial stages (e.g., in Azure DevOps tasks), but when the deployment script (deploy.py) runs, it could be executed in a different context or environment variable scope. The DefaultAzureCredential flow checks multiple credential sources and may not pick up your service principal as expected during the script run.

• Missing Environment Variables:
  Ensure that all required environment variables (AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET) are available in the context where deploy.py executes—not just in the pipeline, but for any subprocesses as well.

• Token Caching/Expiration:
  If there’s a delay or context switch, the acquired token may expire or not be forwarded properly between steps.

• User vs. Service Principal Permissions:
  Sometimes, the initial authentication uses a user identity, but the deploy script is forced to use a service principal, which may lack certain permissions on the Fabric workspace or resources.

---

2. Fabric-Specific Configurations or SDK Requirements

• Required Permissions:
  Double-check that your service principal has all the necessary permissions on the Fabric workspace (Contributor or higher, Data Admin roles if needed).

• Supported SDK/CLI:
  Make sure you’re using the latest Azure SDKs compatible with Microsoft Fabric, and that your service principal is granted necessary RBAC roles both in Azure and in Fabric itself.

• Service Connection in Azure DevOps:
  If using an Azure Resource Manager service connection, verify that it’s set to use the correct service principal and that it’s available to all pipeline tasks and scripts.

---

3. Working Example / Best Practice

Best Practice:
Set the required environment variables explicitly in the pipeline before running your Python deployment script, so DefaultAzureCredential always picks up the correct credentials.

Example YAML snippet:

YAML

- task: Bash@3
  env:
    AZURE_CLIENT_ID: $(servicePrincipalId)
    AZURE_TENANT_ID: $(tenantId)
    AZURE_CLIENT_SECRET: $(servicePrincipalKey)
  inputs:
    targetType: 'inline'
    script: |
      python deploy.py

Python (deploy.py) snippet:

Python

from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient

credential = DefaultAzureCredential()
client = ResourceManagementClient(credential, "<subscription_id>")
# ... your deployment logic ...

• Make sure the pipeline variables (servicePrincipalId, tenantId, servicePrincipalKey) are populated from your Azure DevOps service connection.

Extra Tips:

• If you’re using managed identities (e.g., Microsoft-hosted agent with Managed Identity enabled), ensure the identity has permissions in both Azure and Fabric.
• Use az login with service principal before script runs to confirm credentials are valid (for debugging).
• Log the current principal in your script to be sure which identity is being used.

---

Let me know if you need a full working pipeline example or if you hit any other errors—happy to help you troubleshoot further!