New-AzureResourceGroup unauthorized in VSO build agent - azure-devops

Question

I have a build agent set up on a VM in Azure, that is linked to our Visual Studio Online.
I then have an Azure Powershell build step that runs a script that tries to execute New-AzureResourceGroup.
This results in the following:
New-AzureResourceGroup : Unauthorized
113 ##[error]At C:\BuildAgents\agent\_work\[...]\Deploy-AzureResourceGroup.ps1:47 char:1
114 ##[error]+ New-AzureResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation ...
115 ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
116 ##[error]+ CategoryInfo : CloseError: (:) [New-AzureResourceGroup], CloudException
117 ##[error]+ FullyQualifiedErrorId : Microsoft.Azure.Commands.Resources.NewAzureResourceGroupCommand
I can run these scripts locally with no problem.
I have tried importing a publish settings file in the script, but it seems New-AzureResourceGroup is not allowed authentication this way.
I run the build agent as a service under a local user account (not network service).
Does anyone know how to allow the build agent execute New-AzureResourceGroup?
I hope to be able to do a full continuous deployment including setting up and managing everything needed in Azure, including the resource groups.
UPDATE
According to the article below:
"If you connect using this method [publish settings file], you can only use the Azure Service Management (or the ASM mode) commands."
https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-connect/
I'm assuming this applies to Azure powershell as well.
So, is there really no way of managing resources in azure without using account based authentication?
UPDATE
Thanks to #bmoore-msft for providing the missing piece. I'll just add another screen shot of the link I needed to find to set up the build to run under an actual account.

Answer 1

In Azure Resource Manager you do have to use Azure Active Directory authentication, no certs. So that applies to cli, PowerShell, REST APIs, etc.
In VSO there is a build task for Azure PowerShell. When you use that task you specify a "connection" or subscription to execute the task as... so you save the creds in VSO. You could use a regular PowerShell task, but then you would have to secure the creds yourself.
Finally, when you set up the account connection in VSO, it must be an orgID, MSAs are not supported (PowerShell limitation). Service Principal support is coming.

Answer 2

I also had a lot of trouble using the Azure Resource Manager with VSO.
I finally found a working solution to my problem by creating a Service Principal account with enough rights on the Azure subscription to deploy from Visual Studio Online.
I used this blog post from David Ebbo to create the Service Principal Account: http://blog.davidebbo.com/2014/12/azure-service-principal.html
In VSO I removed the "Azure PowerShell" step and replaced it with a "PowerShell" step. In the PowerShell script I start with logging in the Service Principal account and then deploy my applications using Azure Resource Manager.
More details of my findings can be found on the MSDN forum: https://social.msdn.microsoft.com/Forums/azure/en-US/d5a940e0-ed83-46ff-9efc-045fb9522c5b/ad-auth-from-azure-powershell-in-vso-fails-with-accessingwsmetadataexchangefailed?forum=azurescripting