Azure Pipelines Copy Files Task: Authentication Failed
In my Azure Pipelines I use the File Copy task to copy static files to an Azure blob container, and while upgrading these tasks to the new v4, I came across the following authentication issue:
Authentication failed, it is either not correct, or expired, or does not have the correct permission (ServiceCode=AuthorizationPermissionMismatch)
The documentation on this is not very helpful, and took me way too long to piece together all the bits I needed to know. Here is what I found.
The new v4 of the File Copy Task in Azure Pipelines moved from using AzCopy 8 to AzCopy 10, and with all major updates comes with breaking changes. Both old and new use an Azure DevOps Service Principal to authenticate with Azure, but security is tighter on v4. I assume this has something to do with updating the version of AzCopy.
What wasn’t clear to me was how to get the authentication working, the only info I could find was:
For authorization you will have to provide access to the Security Principal.
What that means is; when you create a Service Connection to an Azure Subscription, an associated Security Principal is also created, and that needs to have elevated permissions to copy files to blob storage.
How to do this
- In Azure DevOps, go to the settings for your project, and click on Service Connections (the URL is something like
- Select the Service Connection you are using for your pipeline task
- Click Manage Service Principal which will redirect you to the Application Registration of the Service Principal. All you need to do here is copy the name (the default format is
- Go back and click Manage service connection roles which will redirect you to the IAM blade of the Azure Subscription. Here you need to assign a role to the service principal of which you copied the name of in the previous step. The roles can either be:
- Storage Blob Data Contributor
- Storage Blob Data Owner
This should be all you need to do to get the build deploying to blob containers. I can’t say this would be simple, as you may need to convince someone with the relevant Azure Permissions to add the role to the Service Principal, like I needed to.