3

Using the new Azure portal, I am trying to add a powershell runbook that will start a specific VM. This is not something that will be run in powershell from my PC, it will instead run as an ARM job. I can't seem to find a way to successfully login.

If running from my desktop in powershell I can just call Login-AzureRmAccount and it will launch a login dialog before running any further steps. From what I've read on the web it seemed that what I needed to do was add a credential to my automation account, retrieve it and then call the same Login method. I've now done that, but still can't log in.

Import-Module AzureRM.Compute
$AutomationCredentialAssetName = "automation"
$Cred = Get-AutomationPSCredential -Name $AutomationCredentialAssetName
Write-Output $Cred
Login-AzureRmAccount -Credential $Cred
Start-AzureRmVm -Name 'myvmname' -ResourceGroupName 'myresourcegroupname'

The credential is being retrieved correctly (get's written to output) but the call to the Login-AzureRmAccount fails with:

Login-AzureRmAccount : unknown_user_type: Unknown User Type At line:10 char:1 + Login-AzureRmAccount -Credential $Cred + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Add-AzureRmAccount], AadAuthenticationFailedException + FullyQualifiedErrorId : Microsoft.Azure.Common.Authentication.AadAuthenticationFailedException,Microsoft.Azure.Com mands.Profile.AddAzureRMAccountCommand

If I don't attempt to log in first I get a message telling me to call Login-AzureRmAccount first.

How do I authenticate from within a runbook so that I can run automation tasks? What am I doing wrong?

BlackSpy
  • 5,563
  • 5
  • 29
  • 38

4 Answers4

9

We have subsequently discovered the the automation account created a connection when created that can be used to login:

$connectionName = "AzureRunAsConnection"
try
{
    # Get the connection "AzureRunAsConnection "
    $servicePrincipalConnection = Get-AutomationConnection -Name $connectionName         

    "Logging in to Azure..."
    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint   $servicePrincipalConnection.CertificateThumbprint 
}
catch {
    if (!$servicePrincipalConnection)
    {
        $ErrorMessage = "Connection $connectionName not found."
        throw $ErrorMessage
    } else{
        Write-Error -Message $_.Exception
        throw $_.Exception
    }
} 
BlackSpy
  • 5,563
  • 5
  • 29
  • 38
  • Hi @BlackSpy , I am in the same spot. I requested the Azure service admin to create a AAD user, with no multi-factor authentication and preferably as 'service admin'. Please suggest whether it worked for you, I have created a ARM deployment template and powershell, would prefer to schedule it as runbook or Timer triggered app, but non interactive login is proving a challenge even with organizational account. Please suggest. – H Bala Aug 23 '16 at 07:30
  • 1
    Hi @HBala. We are still waiting on our IT to setup our AAD. Most of our runbooks exist to provide our devs/testers with the ability to do common tasks that we block access to in the portal, eg. cloning vms requires access to the storage accounts and keys. The method above worked for us. The connectionName maps to a connection on the automation account (under Assets) of type AzureServicePrincipal. Hope this helps. – BlackSpy Aug 23 '16 at 20:52
  • It took me a while to figure this out, but this is the alternative for doing Login-AzureRmAccount Set-AzureRmContext -SubscriptionId $subscriptionId -TenantId $tenantId. The latter only works locally in Powershell. – Tincan Feb 01 '17 at 12:18
1

At a guess you are trying to log in with a Microsoft account, which can only be done interactively (as it needs to redirect through live.com). You will need to create a user within the tenant (Active Directory) that you are authenticating against in order for non-interactive login to work.

The easiest method to make this work is to create an account in the old portal (the new portal doesn't support Active Directory management yet) and then to add that user as a co-administrator in settings > administrators.

You can create a user through Powershell, and assign much more granular permissions, but while you're working your way around things it is probably easier to stay within the portal.

There is no significant difference between a user created through the old portal and one created via AzureRm commands.

Michael B
  • 11,887
  • 6
  • 38
  • 74
  • So you need to run Azure Active Directory just to run a script on a schedule? – BlackSpy Jan 21 '16 at 21:24
  • If you have an Azure account, you already have Azure Active Directory - have a read of this - [How to get an Azure Active Directory tenant](https://azure.microsoft.com/en-gb/documentation/articles/active-directory-howto-tenant/) which covers the basic concepts – Michael B Jan 21 '16 at 21:26
  • A little more clarification.... While I have previously attempted to create the credential using a microsoft account (and get the same error) I am currently using the Credential I created in the new Azure Portal (Automation Account->Assets->Credentials) which is what gets retrieved by the Get-AutomationPSCredential call. I get same same error either way. The link you sent refers to the old management console and considering that all my method calls are the Resource Manager versions, is this going to make any difference? – BlackSpy Jan 21 '16 at 21:35
  • The Credentials dialogue in Automation Accounts is for specifying the credentials that you have previously created. Creating an account there doesn't grant any Authentication permissions it is simply the credential that is (blindly) added to commands that try to authenticate. - I have updated the answer a little – Michael B Jan 21 '16 at 21:47
  • Ok, so I create a new account in AD, then how would i use that to log in? Do I create a credential object manually with a username and secureString password? – BlackSpy Jan 21 '16 at 21:50
  • Yes, exactly that. You will need to grant the user account permissions, the easiest method would be to add the user as a Service Admin when you create the user in the old portal. (its been a while since I've been there!) – Michael B Jan 21 '16 at 21:55
  • Thank you sir :). That was it exactly – BlackSpy Jan 21 '16 at 22:23
0

I just encountered the same problem and while the information posted here was helpful it didn't solve the problem completely.

The key insight I needed was that in order to use Azure Cmdlets one has to configure a 'Run as Account'. (See https://learn.microsoft.com/en-us/azure/automation/automation-sec-configure-azure-runas-account) It can be set up under Account Settings section of the azure automation account.

Once you have the 'Run as Account' you can use the method proposed by BlackSpy to log in. Namely:

# Get the connection
$servicePrincipalConnection = Get-AutomationConnection -Name AzureRunAsConnection         

"Logging in to Azure..."
Add-AzureRmAccount `
    -ServicePrincipal `
    -TenantId $servicePrincipalConnection.TenantId `
    -ApplicationId $servicePrincipalConnection.ApplicationId `
    -CertificateThumbprint   $servicePrincipalConnection.CertificateThumbprint 

Hope this might help someone.

Peter
  • 1,361
  • 15
  • 19
0

The official advice is to use a ServicePrincipal for automation - you can either use Secret or Certificate credentials with a service principal, and certificates work the best.

It is still possible to use a work or school account for automated login (Login with just -Credential), but this requires that your organization does not require two-factor authentication. It is unfortunately not possible to use a Microsoft Account for this - microsoft accounts require user interaction for any login.