Follow Us

Automating Azure Resource Group deployment using a Service Principal in Visual Studio Online: Build/Release Management

Connect your Azure subscriptions to VSTS in 3 clicks

New improved user experience to setup Azure Resource Manager based service connection in VSTS.

Follow the post below to configure Visual Studio Team Services to communicate with Azure in order to provision or deploy Azure Resource Manager resources such as virtual machines

To setup Azure Service end point in VSTS, from your Visual Studio Account, navigate to your Team Project and click on gear icon.

Navigate to Services tab and click on ‘New Service Endpoint’ in the left pane.

From the drop-down, select ‘Azure Resource Manager’ option.

Now, setting up an Azure Service endpoint is easy, you just need to select the subscription on which to create a service endpoint, and you are ready to deploy to Azure.

Note:

A new Azure Service Principal will be created and assigned with the ‘Contributor’ role. The default role assignment will have access to all the resources in the selected subscription. You can modify the Service Principal access from Azure portal > Subscriptions > Users > Roles.

If your subscription is not listed or to specify an existing service principal, click the link in the dialog, which will switch to manual entry mode.

Once successful, the script would output the following details for the Azure Service Endpoint.

Connection Name

Subscription Id

Subscription Name

Service Principal Client Id

Service Principal key

Tenant Id

To setup Azure Service end point in VSTS, from your Visual Studio Account, navigate to your Team Project and click on gear icon.

Click Services tab and click on ‘New Service Endpoint’ in the left pane.

From the drop-down, select ‘Azure Resource Manager’ option. In the dialog, click the link at end of the text “If your subscription is not listed or to specify an existing service principal, click here”, which will switch to manual entry mode. You can always switch back to “Auto creation of SPN mode” by clicking the link in the manual mode dialog.

Enter the input values that you generated from the PowerShell

Click ‘OK’’. We now have established a connection to Azure from your VSTS account.

From Build/Release hub, now you add “Resource Group Deployment Task” (for example) and use the subscription.

The above steps are sufficient for the purpose described. If you would like to rather create the service principal on your own instead of using the above script, then follow these steps below:

To create an Azure Active Directory application, login to your Azure account through the classic portal.

Select Active Directory from the left pane.

Select the directory that you want to use for creating the new application.

To add a new application in your directory, click on Applications and click on Add.

Choose “Add an application that my organization is developing”.

Select WEB APPLICATION AND/OR WEB API and click the next button.
Though we intend to automate Azure Resource Group deployment from VSTS, we will have to create a Web App and use its service principal to authenticate with Azure Resource Manager.

Enter a recognizable URL as we will need it later for role assignment.

The existence of the web-site is not validated. We are registering a web app name-space so that we can create a Service Principal identity for the application.

Congratulations, you now have an AAD Application. Click on the CONFIGURE tab:

To create your service principal password, from CONFIGURE tab, find Client ID and copy it. This will be your Service Principal user name.

From the “keys” section, from the drop-down select 1 or 2 year duration.

After you hit save at the bottom, it will display your key, which is basically your Service Principal account password. Copy and store the key value. You won’t be able to retrieve it later.

You have now created a service principal in the directory, but the service does not have any permissions or scope assigned. You will need to explicitly grant the service principal permissions to perform operations at some scope. You will need to use http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/. Log in as your Microsoft identity in order to grant roles to your Service Principal identity.PS C:>Switch-AzureMode -Name AzureResourceManager
PS C:>Add-AzureAccount # This will pop up a login dialog

Assign roles to your Service Principal. For now, giving it access to the whole subscription. You can limit the access by providing the scope parameter. You can use either App ID Uri or Client ID as the value for the -ServicePrincipalName parameter.PS C:>New-AzureRoleAssignment -ServicePrincipalName http://RNWebAppforVSO -RoleDefinitionName Contributor

If you run Get-AzureRoleAssignment, you should see the assignment.

Above commands work with older version Azure PS modules. If you are on latest Azure ARM PS modules, you need to use equivalent RM command-lets. For example, Add-AzureRMAccount, New-AzureRMRoleAssignment etc.

You could also do role assignment to your application from the new Azure portal. Click Browse and select Subscriptions. Select the subscription you are using. Click the Access button.Click Add. Select Contributor as the role. Search and select the name of the application you just created. Click OK to grant the service principal access to your subscription.

Comments

Hi there,
When I execute the cmdlet "New-AzureRoleAssignment -ServicePrincipalName [url] -RoleDefinitionName Contributor", I get the following error:
New-AzureRoleAssignment : The term 'New-AzureRoleAssignment' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I'm using MS Azure Powershell version 1.0.1
Can someone assist me please?
Thanks,
Judy

Is this supposed to work on-premise. We are using TFS 14.0.24712.0 (Update 1), but when I try to set it up i get "User does not have required permissions for the service endpoint"
If I use the exact same service principal from VSO it works fine. But I can see the setup dialog looks different in VSO, so obviously not the same version.

@Simon,
Yes, UI has undergone changes in online.
Can you please elaborate? you mentioned if you use exact same service principal as that of VSO it works fine on on-premises, right?
By default Service Endpoints are secured and only the owner(creator) and EndPoint Admin groups have access to it. If you need to share you need add the users to Endpoint Readers group for the service connection.

@Roopesh
It might be a permission issue on or onprem TFS (I'm just admin of the project, not the collection).
I am in project administrator group which are in the endpoint administrators. I get an error, when I try to save:
User does not have required permissions for the service endpoint.

@Simon,
You need to be member of "Endpoint Creators” group. If you've "Contributor" role you should get it by default.
As a Team Project Administrator, you are a member of the “Endpoint Administrators” group, but not of the “Endpoint Creators” group.

I ran through via portal, but when I run Azure File Copy task in the new build system, it fails and says the storage account doesn't exist (it does exist though). When I look at the log it mentions trying RDFE before trying ARM. I spent a number of hours trying to trouble shoot it but it seems to initially connect to the subscription but when it goes to connect to the storage account, it's like it tries to fall back to using credentials which obviously provided and seems to try rdfe first – isn't that the classic mode compared to ARM. Any ideas why

The override template parameters in VSO -vmName $(vmName) do not appear to to carry through to (parameters(‘vmName’) in the custom script extension and deployment fails if the override parameters are different than is specified in the azuredeploy.parameters.json. It’ll work through if the azuredeploy.parameters.json is hard coded to the same VM name as specified in the configuration variables of -vmName $(vmName).

Is there any movement on use of a Service Principal for Azure App Service deployments, we have a bit of an issue with use of management certificates, as they provide full access to an entire subscription rather than being able to be scoped to individual resource groups (like a Service Principal can be).

We have had a couple of occasions now where a build administrator from one of the projects in our default collection has accidently typed the Web App name of another project in the target of a deployment task, thus the deploy task of the release then overwrote the Web app for the wrong project which caused two project teams to spent a good few hours attempting to figure out why all their code had stopped working!!.

When subscription name contains non english characters the script fails when creating the new AAD application.
New-AzureRmADApplication : {“odata.error”:{“code”:”Request_BadRequest”,”message”:{“lang”:”en”,”value”:”Invalid value found for property ‘identifierUris’ of resource ‘App
lication’.”},”values”:null}}
I fixed this by replacing my non english char: $subscriptionName.Replace(‘ ‘, ”).Replace(‘å’, ‘a’).
A more generic solution should be implemented.