Hello!

I’ve recently started a new project, and we’re going to use VSTS for the build and release pipeline. This includes deploying infrastructure from ARM templates. This is going to provide its own set of challenges, in that the VSTS Team is new and there is no authentication between VSTS and the Subscription the objects are deploying to. So it really is a “green field” project. But this is a good thing, as we get to deploy as much as we can from source control and limit the interaction with the Azure Portal.

Wrt the aforementioned authentication, there’s two ways you can do this -

Create the Service Principal Name automatically when creating Service Endpoint in VSTS

This process is covered quite well elsewhere, such as Microsoft Docs, and this post on GitHub covers the very basics. Creating a SPN as part of creating a service endpoint may be the way to go if you’re just playing around on a non-enterprise accounts for Azure/VSTS.

Create the Service Principal Name manually prior to creating the Service Endpoint in VSTS

In terms of easiness, the 1st option is definitely the way to go. And I like things that are easy. However easy is not an option for us, and this is because when you create the SPN automatically, the SPN is assigned the Contributor role in the Azure Subscription. This allows the SPN to alter resources in the subscription. But to assign the SPN to a role, the person creating the service endpoint in VSTS need to be an Owner or Subscription Admin in the Azure Subscription. Which sadly I am not. So no permissions, no joy.

So the alternative is for the Sub Admin to create the SP for us. Fortunately Microsoft have provided the PowerShell script that will create a SP specifically for a VSTS service endpoint on GitHub. Useful! It can also be created through the portal. And this is also documented via Microsoft Docs.

The creation of a service endpoint is simple enough, providing you have the necessary info. Go to the Settings (ie the cog) on your VSTS homepage and select “Services”, then on the left select the New Service Endpoint -> Add Azure Resoure Manager Service Endpoint-

If you don’t have most of this info you can get it fairly easily by following this post (except for Service Principal Key, if you don’t have that and it wasn’t copied down when it was created it is lost to the mists of time…).

So, SPN created, and we’re good to go and create the service endpoint, right? Well in my case, sadly not. I seemed to be having some random issue about a “forbidden 403” event happening when I clicked the “verify” link. This is the full error -

Failed to query service endpoint api: https://management.azure.com//subscriptions/ab9d1614-[redacted!]?api-version=2016-06-01. Error Message: The remote server returned an error: (403) Forbidden..

Turning again to the ubiquitous Microsoft Docs, I found a troubleshooting page. Yet my error was not amongst the issues. I knew that I was a contributor on the subscription, and that I had the right permissions to create the endpoint in VSTS. At any rate, I had all the correct credentials.

It took most of the day, and some fruitless Googling, but I eventually stumbled upon this post titled Create Azure Service Principal for VSTS, which wento into details about using the Azure CLI to login as the Service Principal, so I thought I’d give that a go to verify everything was correct.

Everything WASN’T correct- what had happened was that when the Service Principal was created via the Portal, it was not assigned the role in the appropriate subscription! D’oh! Still, a quick and simple fix as it was covered on the Microsoft Docs page mentioned earlier. Once the Service Principal had the correct role and could connect to the Subscription, the Service Principal correct verified and I can now deploy ARm templates to Azure. Hooray! What I should do now is edit the Microsoft Docs troubleshooting page in GitHub and hopefully get a pull request approved.