Login-AzureRmAccount does not work with Microsoft accounts

[doctordns]

Cmdlet(s)

Login-AzureRmAccount

PowerShell Version

Instructions: to get PowerShell version, type $PSVersionTable and look for the value associated with PSVersion
5.1

Module Version

Latest - 3,0.0

OS Version

Instructions: to get OS version, type $PSversionTable and look for value associated with BuildVersion
Win10 AU - 10.0.14393.206

Description

The cmdlet does not support MS accounts. Since MS accounts are surely implemeted in Azure -not sure why can't we use them programatically.

Debug Output

Instructions: to get Debug Output, set $DebugPreference="Continue" and then execute the cmdlet or script causing the issue

Not needed - just try it and you will see

Script/Steps for Reproduction

Easy: run the cmdlet and try to specify a MS account. You either get errors or the gui.

[cormacpayne]

@doctordns Hey Thomas, I am unable to reproduce this issue with my corp or outlook email. Can you please post the debug output from this command call?

[doctordns]

If I use Get-Credential to gather the credential, I see this;
PSH [C:\foo\test]: $CRED = Get-Credential tfl@msn.co.uk

PSH [C:\foo\test]: Login-AzureRmAccount -Credential $CRED
Login-AzureRmAccount : unknown_user_type: Unknown User Type
At line:1 char:1

• Login-AzureRmAccount -Credential $CRED

• - CategoryInfo          : CloseError: (:) [Add-AzureRmAccount], AadAuthenticationFailedException
  - FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.AddAzureRMAccountCommand
  

[pcgeek86]

@doctordns The -Credential parameter cannot be used with Microsoft Accounts. It's somewhat subtle in the help, but it's technically documented. Notice how it's specified that the -Credential parameter is used to provider "organizational ID" (aka. Azure Active Directory (AAD)) credentials, not Microsoft Accounts.

PS C:\Users\TrevorSullivan> Get-Help -Name Add-AzureRmAccount -Parameter Credential

-Credential [<PSCredential>]
    Specifies a PSCredential object. For more information about the PSCredential object, type Get-Help Get-Credential.

    The PSCredential object provides the user ID and password for organizational ID credentials, or the application ID
    and secret for service principal credentials.

    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false

[markcowl]

@doctordns @pcgeek86 Correct. Unfortunately, MS accounts (that is, accounts that are not work or school accounts) cannot be used in the non-interactive flow.

The advice for automating is to create and use a service principal. See: https://gist.github.com/devigned/dae74a7ca54000f7b714 for a script that will create (and login) as a service principal

[markcowl]

Closing, as this is a platform limitation.

[doctordns]

Sorry - this may be a platform limitation, but it is also a limitation on the PowerShell cmdlets. The Azure team says to complain here, but you say no.

Why is NO ONE willing to accept this is a limitation and to offer a solution?

Frankly, as the person asking this questin, I do not accept it as being closed.

[kilasuit]

AFAIK - hotmail accounts or other "Microsoft accounts" have never been supported from previous conversations that I have had in the past which pointed to a re and unlikely will ever be supported as per @markcowl details above.

Your better off creating an Azure AD Directory and creating an administrative account that does have administrative control over the subscription or a Service Principle as suggested.

Regarding this

Sorry - this may be a platform limitation, but it is also a limitation on the PowerShell cmdlets

That would be technically incorrect as there is no limitation on the PowerShell cmdlets but the underlying platform they interact with which is exactly what was mentioned by @markcowl above and has been discussed in other issues here beforehand as well.

Also

Why is NO ONE willing to accept this is a limitation and to offer a solution?

See the offered solutions above especially where it has been acknowledged there is a platform limitation.

Personally I would rather kill off the ability to register via Microsoft accounts completely as for almost all scenarios you will add Azure AD into the mix anyway (or should for RBAC reasons even in demo environments)

[pcgeek86]

Personally I would rather kill off the ability to register via Microsoft accounts completely as for almost all scenarios you will add Azure AD into the mix anyway (or should for RBAC reasons even in demo environments)

Agreed with this. Microsoft is working to consolidate Microsoft Accounts and Azure Active Directory accounts. In general, as mentioned by @kilasuit, you should use Azure Active Directory (aka. organizational / work / school) user accounts for authentication to Azure services.

For non-interactive background worker processes, as @markcowl has already mentioned, the recommendation is to utilize Azure Active Directory Service Principals (aka. Applications).

[doctordns]

It is still a bug. If you think about it, MS Accounts live up in Azure. So it should not be an issue.

I would like this fixed.

AND in the mean time, the Cmdlet should explicitly return an error that is less weird!

From: Trevor Sullivan [mailto:notifications@github.com]
Sent: 23 October 2016 19:56
To: Azure/azure-powershell azure-powershell@noreply.github.com
Cc: Thomas Lee doctordns@gmail.com; Mention mention@noreply.github.com
Subject: Re: [Azure/azure-powershell] Login-AzureRmAccount does not work with Microsoft accounts (#3108)

@doctordnshttps://github.com/doctordns The -Credential parameter cannot be used with Microsoft Accounts. It's somewhat subtle in the help, but it's technically documented. Notice how it's specified that the -Credential parameter is used to provider "organizational ID" (aka. Azure Active Directory (AAD)) credentials, not Microsoft Accounts.

PS C:\Users\TrevorSullivan> Get-Help -Name Add-AzureRmAccount -Parameter Credential

-Credential []

Specifies a PSCredential object. For more information about the PSCredential object, type Get-Help Get-Credential.



The PSCredential object provides the user ID and password for organizational ID credentials, or the application ID

and secret for service principal credentials.



Required?                    false

Position?                    named

Default value                none

Accept pipeline input?       false

Accept wildcard characters?  false

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/3108#issuecomment-255606816, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADdk-ek2NazetpRKId9za932ANEuRsVJks5q262wgaJpZM4KdKJO.

---

This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com

---

---

This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com

---

[pcgeek86]

You're more than welcome to want it to be fixed, but the chances of that happening are very slim. Considering that Microsoft is investing in consolidating the login experience, that further reduces the chances of them spending time on a short term solution.

It might not be a bad idea to improve the error message though. I agree that this is quite vague:

add-azurermaccount : Sequence contains no elements

@markcowl I'll open a work item for this, as I was able to reproduce the vague error message. The work item is simply to improve the messaging, nothing more.

[pcgeek86]

I filed a new issue here, for the purposes of improving the error messaging.

#3121

[markcowl]

@doctordns Understand that I agree with you on the asymmetry between supported scenarios for work/school and msa accounts, it is counter-intuitive and we should not expose it to our users. Unfortunately, it is not supported by AD so there is nothign we can do about supporting versus not supporting it.

We can return a better error message, however, to point users at the right solution.

[dirkesquire]

I came across this same issue in 2017, 1 year later.
I find it strange that
Login-AzureRmAccount
works just fine for personal (live accounts), despite all the comments above that 'the platform doesn't support this'.
However if you try to pass in $creds as a parameter, this is where it falls over:
$creds = Get-Credential
Login-AzureRmAccount -Credential: $creds

The error message is still just as vague: unknown_user_type: Unknown User Type

It is obviously expecting an Org account and getting a Live account. We just need an additional parameter to tell it this is a Live account.

[juancrl]

Totally agreed. It is not a bug, but an incomplete feature.

You can always login with a Live Account interactively (Connect-AzureRMAccount), which means REST/ADAL/Whatever is on the server side can understand and authorize this account. It also works when you Import-AzureRMContext with a saved JSON file.
But it does not work when the credentials are passed as a -Credential parameter ???
It breaks automation totally (I have an scenario where I must use multiple Live Accounts, not a service account)
Running Connect-AzureRMAccount with and without -Credential, and with -DEBUG, might give some hints.
Exactly quoting Dirk (whose English is better),
"It is obviously expecting an Org account and getting a Live account. We just need an additional parameter to tell it this is a Live account."

And the error "The sequence contains no elements" shows a lazy or inexistent effort to parse error codes..