Mystery of the fabric-cicd authentication that never was

Reading Time: 3 minutes

In this post I cover the mystery of the fabric-cicd authentication that never was. To help others who experience similar issues with fabric-cicd.

Allow me to explain. A while back I encountered issues whilst testing some things for the Azure DevOps version of the FUAM deploymenator.

Which is a FUAM deployment accelerator that I developed in order to push FUAM deployments from Azure DevOps to a Microsoft Fabric tenant. Like in the overview diagram below.

I had copied the same logic over from the GitHub version of the FUAM deploymenator to authenticate as a service principal and deploy with fabric-cicd.

Deploying with fabric-cicd in the same tenant worked fine. However, when I attempted to populate the workspace with fabric-cicd in another tenant I was getting the below error.

Unhandled error occurred calling GET on 'https://api.powerbi.com/v1/workspaces/{MyWorkspaceId}/folders'.

I was experiencing this issue on a couple of separate tenants. So, the first thing I did was check that the Tenant admin settings were the same in another tenant.

Once I had matched the tenant settings, I tested deploying with Azure DevOps again and it failed. I then tested deploying in an Azure DevOps organization in the same region as the other tenant. Which also failed.

I then tested the GitHub version of the FUAM deploymentator on the same tenant. Which worked fine. I then ran the PowerShell involved locally as well, which also worked fine.

However, I was still experiencing issues when attempting to deploy in Azure DevOps. So I enabled verbose logs in Azure DevOps and debugging in fabric-cicd. In order to investigate further.

Authentication that never was

After further investigation I discovered I was getting 404 issues. Which typically relates to authentication issues.

However, my authentication appeared to be fine according to Azure DevOps. The task appeared to be completed, and it showed the tenant name as below.

But it was still looking like an authentication issue. So, I tested adding quotes around the parameter for the service principal secret in the PowerShell task that performs authentication as below.

- task: PowerShell@2
  displayName: 'Authenticate as Service Principal for fabric-cicd'
  inputs:
    targetType: 'inline'
    script: |
      Install-Module -Name Az.Accounts -AllowClobber -Force

      $SecureStringPwd = ConvertTo-SecureString '${{parameters.azure_client_secret}}' -AsPlainText -Force
      $pscredential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList ${{parameters.azure_client_id}}, $SecureStringPwd
                        
      Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant ${{parameters.azure_tenant_id}}

      $fabricToken = (Get-AzAccessToken -ResourceUrl $(resourceUrl)).Token
    pwsh: true  

All of a sudden, my fabric-cicd deployments started working. Which means that the completed authentication task had been misleading all along.

So, if you encounter a similar issue whilst working with PowerShell tasks in Azure DevOps I recommend testing with quotes.

Final words about the fabric-cicd authentication that never was

I hope that by the mystery of the fabric-cicd authentication that never was I help others who experience a similar issue. Because Azure DevOps showing the authentication task as completed was misleading.

In addition, it advocates working with service connections instead when looking to deploy with fabric-cicd. As shown in the post by Richard Mintz.

Of course, if you have any comments or queries about this post feel free to reach out to me.