Connect-AzureRmAccount with user credential login does not work in Az 0.2.2

[slavizh]

Description

Connect-AzureRmAccount does not work in Az 0.2.2 with credentials specified. It asks for ServicePrincipal which is not correct as I use user credentials.

Script/Steps for Reproduction

$credential = Get-Credential
$tenantId = "XXX"
Connect-AzureRmAccount -TenantId $tenantId -Credential $credential -ErrorAction Stop
cmdlet Connect-AzAccount at command pipeline position 1
Supply values for the following parameters:
ServicePrincipal:

Module Version

Get-Module -ListAvailable
Script     0.2.2      Az.Profile                          {Disable-AzDataCollection, Disable-AzContextAutosave, Enab.

Environment Data

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.17763.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Debug Output

Debug cannot be run as the cmdlet does not allows you to start.

[cormacpayne]

@slavizh it looks like the parameter set that is missing has been if-def'd in the Az module, as seen here. Will need to do some investigation to see if this is a scenario that we want to support in Az.

[cormacpayne]

@slavizh whoops, I should've just looked at the blame for the lines highlighted above 😀 we added this if-def due to the following issue: #5785

In this issue, a comment was made by @markcowl that will clarify the above error:

This is by design. Usename + Password authentication is not supported in NetCore - you must use device login or service princpal login

You can find more information in the issue linked above, but as a result, I'm going to close this as "by design".

[slavizh]

@cormacpayne OK but as far as I understand Az is replacement of AzureRM. Shouldn't that grantee backwards compatibility? in you Az document you say "To make it easier for existing scripts to migrate from AzureRM to Az, we have provided cmdlets to create aliases that map the cmdlet names in AzureRM into the appropriate cmdlets in Az. When the aliases are enabled, any script that uses AzureRM cmdlet names should run against Az without modification." Sounds like it is not like that. We are CSP and we cannot use Service Principals currently so we have to use user accounts for automation even that we do not like it. With this issue you are basically leave us at a dead end.

[jseerden]

I agree with @slavizh. In the https://github.com/Azure/azure-powershell/blob/preview/documentation/announcing-az-module.md docs you state:

To make it easier for existing scripts to migrate from AzureRM to Az, we have provided cmdlets to create aliases that map the cmdlet names in AzureRM into the appropriate cmdlets in Az. When the aliases are enabled, any script that uses AzureRM cmdlet names should run against Az without modification.

In the current AzureRM module, you can use User Credentials for non-interactive logins. In the current Az module, with the aliasses enabled (Enable-AzureRmAlias), this will break, so they require modification. This is not in line with the documentation.

[cormacpayne]

@slavizh @jseerden thanks for the comments and concerns over this issue. One thing I want to make sure is noted is that we are working to convert as much as the previous functionality from AzureRM to the Az module, but we are limited in some aspects due to the new target framework (.NET 4.5.2 --> .NET Standard 2.0). One place where this affects us is the use of the Active Directory Authentication Library (ADAL) -- moving to a version of ADAL that supports the new target framework has resulted in a couple of changes that you may have noticed when using the previous AzureRM.Netcore module or the new Az module:

(1) There is no interactive login -- when running the command Connect-AzAccount with no additional parameters, rather than being prompted by UI to provide the username and password of the account you want to authenticate with, you instead see the device code login, which asks you to open the provided URL in a browser and provide the given code, which will then authenticate you as normal. Since ADAL doesn't support this UI prompt that was previously seen, the device code login is now the default login mechanism for the Az module; however, we do have plans to support our own interactive login in an upcoming release.

(2) Username and password is not supported -- back to the issue at hand 😀 currently, ADAL does not support username and password authentication, which is why we removed the -Credential parameter from being provided outside of the service principal parameter set for Connect-AzAccount in the AzureRM.Netcore module (which can now be seen in the Az module). From ADAL's wiki page, you can see the note on how this authentication scenario is not recommended, as well as how you can only get the token from this authentication in .NET Framework.

Side note: if you're interested in what forms of authentication will and won't work in ADAL against different frameworks, they provided tables for public client applications and confidential client applications that I'd recommend checking out.

Moving forward, where applicable, we recommend moving away from the username/password form of authentication and creating a service principal with the proper permissions that you will need to run the same script that you're looking to run with your account (or the account whose credentials you were previously providing). As mentioned in the links above, this is safer than using the username/password authentication and is a mechanism that is supported by the ADAL library on both target frameworks. I will need to get back to you on the CSP scenario, since you mentioned that you are unable to use service principals in that case.

Please let me know if you have any questions or comments!

[slavizh]

@cormacpayne I appreciate the detailed explanation. I hope you will be able to understand the CSP scenarios as currently we are locked to using user name and password credentials. As soon as that situation changes for CSPs we will of course move to service principals. It will be easier for us as well to manage SPs rather user credentials.

[kilasuit]

@cormacpayne - DeviceLogin isn't scale able when you have multiple accounts or any automation usecases that are outside of azure talking into azure. Especailly on the Windows side, where you will be breaking peoples workflows for interacting with Azure.

Please provide this critical core functionality back in if you want any real adoption of Az

Otherwise I'll recommend users stick to AzureRM

[MiYanni]

@kilasuit Can you elaborate on which workflows will be broken for Windows users? As pointed out above, this change is due to security concerns, which is why ADAL pulled the functionality from latest versions. See @cormacpayne's comments above for more details.

[markcowl]

@slavizh @jseerden @kilasuit Using username/password login with stored credentials is not supported for security reasons - using this means that you cannot set your tenant for multi-factor authentication, and the recommendation for some time has been using SPN credentials for automation.

If you can share some scenarios that are no longer enabled, and cannot use service principal authentication for a legitimate reason, please let us know what those are.

[jseerden]

You're breaking CSP management options to connect with multiple tenant's using Delegated Administrative Permissions.

Documented here: https://docs.microsoft.com/en-us/azure/cloud-solution-provider/overview/azure-csp-management-options

The method to connect is using a partner's user credentials (username/password):

# Get a partner's user credentials.
$credentials = Get-Credential '<username@domain>'

# Authenticate and connect to Microsoft Azure.
Login-AzureRmAccount -Credential $credentials -TenantId $customer.CustomerId

For example: We wrote our own multi-tenant automation task that stops and starts Virtual Machines during off-hours. This is a multi-tenant solution that we've made available even before https://docs.microsoft.com/en-us/azure/automation/automation-solution-vm-management
was released, which does not suit our needs, because it is single-tenant.

I agree that using a Service Principal is the way to go. But can we create and use these on Partner level?

[Lachlan-White]

Just run into this issue, this is a big breaking change thats going to cause alot of issues for a lot of people!

[jamesmealing]

We have an almost identical situation to @jseerden above. How is this supposed to work for CSP's?

While I agree that storing user credentials can be a security concern, however, when the only place those credentials are stored is in an Azure Automation Account Credential object, that concern largely goes away...

[markcowl]

@jamesmealing @a138076 @jseerden While I agree that breaking changes are painful and should be avoided except when absolutely necessary, any solution we provide in this area would be temporary, at best.

Using a stored password means that you have not enabled multi-factor authentication, which, along with storing passwords, and using credentials that are not scoped to a particular tenant are all fundamental security concerns with authenticating automation that would need to be addressed in the future.

I agree that CSP authentication appears to leave no good, secure options for automation, unless your automation is tied to a client tenant.

[lwajswaj]

I understand SPN are kind of a solution but it isn't as secure as we are preaching here since I'm replacing a user ID with another which, the "password" (secret) expiration is longer than a user password and also cert authentication isn't supported right away. Plus, Enterprises have configured their Admins users with a set of two credentials: primary accounts and privileged accounts) which they might be in the same AD or AAD if using O365) when, in general, second ones are already under some vaulting and automated password rotation with already some sort of MFA to retrieve it.
I don't think you should force people to change this kind of things but leave it available but not recommended if you will, but still we should have a choice. Also, it's unrealistic to push everybody to change their procedures and ways of working in two months (keep in mind there might be contractual requirements). Just my two cents

[jamesmealing]

@lwajswaj makes an extremely good point and is also something I've never fully understood... Why is the password of an SPN any more secure than the password of a properly managed service account?

The "Create an Azure service principal with Azure PowerShell" article has a section called "What is a 'service principal'?" - Based on the description here, the only difference I can see is the recommendation for "tightly controlled permissions", which is something we already have when using delegated admin in CSP.

I also whole heartedly agree that making this a forced change, especially in the timeframes discussed here, is unreasonable at best.

[markcowl]

@jamesmealing @lwajswaj

This is an excellent question. There are a few reasons why service principals are considered a better fit for authenticating automation

• Service Principals are scoped to a particular tenant
• Service Principals do not receive Refresh tokens on authentication - they must reauthenticate whenever access tokens expire
• Service principals automatically have credential expiration
• SPN will soon disallow choosing passwords
• SPNs are created expressly for authenticating automation, and so can be more readily scoped for least privilege than user accounts

Some of this is basically security by design - that is, enforcing best practices that could be followed with scoped user accounts (i.e. user accounts that are *only used for particular automation) and good security policy. This is a case of letting users fall into the pit of success security wise. However, the lack of refresh tokens is a significant difference that cannot be replicated (AFAIK) through poilicy.

One challenge of the 'secuity by design' approach is managing the transition to security by design in a way that minimizes the impact on our users, which is one reason we are looking at continuing to support this authentication flow for some period of time in the new module.

[lwajswaj]

Hey @markcowl, I understand the points however that's why I already have in place other mitigations for this type of security concerns (such as Azure AD PIM with approval flows to elevate my credential).
I understand and see the benefit of constraining access to the SPN to whatever task in particular but that's not what the market is doing, not even Microsoft partners (such as Terraform and others) which are expecting a single SPN to be able to automate against the whole subscription or even tenant; basically, those tools are not prepared to work with multiple SPN. I'm not even sure how Azure Automation Accounts would react switching context in the middle of the runbook. So, although we all try to adhere to least privilege, we are not widely ready for some of the changes and, even more, when we try to fix security in a particular thing (like this) without fixing bigger issues (like Azure Portal leaving the session alive for more than a day). To me, besides every security justification, this seems to just respond to .NET Core 2.0 not supporting ADAL with UI, I understand it's not the best option but I still should have the choice same as Azure DevOps Services does (it provides several auth method even PAT which is the less secure of all). So, option should be on my side since I can have different mitigations.

I agree the lack of refresh tokens is a good point but I think this change will end up having an opposite result from what you expect since it will happen that for each Admin account you will have an SPN created with a secret expiring in 50 years (literally, there are examples at docs.microsoft.com that shows that and even the cmdlet doesn't force any specific amount of time) with full access in the subscriptions. Not saying it's the right way to do it but I think that's the reaction you will generate.

Glad to read you are looking at continuing supporting this authentication flow for a time because this whole thread seemed to be related to Az 0.2.2 module no longer supporting it and then all the justification around security seemed to be a derail from the original point. Just being candid with my perception of the thread.

Thanks for considering the points

[jamesmealing]

@markcowl thank you for the detailed reply and for the ongoing conversation here, however, @lwajswaj has just summarised the multitude of issues with this superbly. Principally, this feels very much like an excuse for .NET Core's lack of ADAL support cleverly disguised as a security best practice...

The long and the short of it is this change leaves CSP's with no viable option with regards to automation spanning multiple tenants as there is no concept of a CSP level SPN, with delegated admin/admin on behalf of. That is a huge breaking change.

[rnsc]

hello @markcowl , how much interest is required by the community to have that feature available on Az for Powershell 6 on Linux?

Also: this documentation is misleading:
https://docs.microsoft.com/en-us/powershell/module/az.accounts/connect-azaccount?view=azps-1.0.0

It basically says that you can use a Credential object to connect, which is completely false.

[markcowl]

@rnsc So the syntax is correct, but the examples haven't been updated to reflect this.

I don't think we need any additional feedback, except to prioritize this versus other features - it turns out to be quite a bit more work to support this cross-platform.

[markcowl]

@slavizh @jseerden @rnsc @ClericC @jamesmealing @lwjswaj @kilasuit FYI that this feature will not ship tomorrow, but will ship by 1/22. We are currently testing the release candidate for this fix.

[ghost]

@jseerden, @markcowl, and @slavizh I have been reading through this issue and I wanted to share some details regarding the CSP scenario. Microsoft will soon be requiring multi-factor authentication for users access the Partner Center Dashboard and with the Partner Center API when using app + user authentication. Due to this change the secure application model. This model provide guidance on how partners can leverage a stored refresh token, that was obtained interactively, to request access tokens. I wanted to mention this because you can use an access token to authenticate with the Azure PowerShell Module.

In the coming days I will be publish additional guidance on how partners can utilize this new guidance to connect using PowerShell. Currently I only have details for the Partner Center PowerShell module and MS Online published. For complete details see, Partner Center PowerShell | Secure App Model

[slavizh]

@IsaiahWilliams Thank you! Please share that example. If we can login with that token to Az modules unattended will fix this scenario. I am assuming that we will have to use that same token once every 90 as the token used in Partner Center API. The user we use for automation will not have any permissions besides Admin Agent (thus gaining owner rights on Azure tenant subscriptions). We have already implemented the new authentication model for automating tasks towards Partner Center API and for users using the portal.

[ghost]

Hi @slavizh,

Yes, you will be able to use the same refresh token you have captured for the Partner Center API. As long as the Azure AD application you are using has the Azure Service Management API added under the required permissions. When using the older Azure PowerShell module you can use something like

$credential = Get-Credential
$token = New-PartnerAccessToken -RefreshToken $refreshToken -Resource https://management.azure.com/ -Credential $credential -ServicePrincipal -TenantId <TenantId>
$graphToken = New-PartnerAccessToken -RefreshToken $refreshToken -Resource https://graph.microsoft.com -Credential $credential -ServicePrincipal -TenantId <TenantId>

Connect-AzureRmAccount -AccessToken $token.AccessToken -GraphAccessToken $graphToken.AccessToken -TenantId <TenantId>

When the Get-Credential command runs you will want to specify the application identifier and application secret used when you captured the refresh token. Since you are using a web application Azure AD requires that you present the application secret, so this is a required configuration.

With respect to the new module you will want to do something similar to the following

$credential = Get-Credential
$token = New-PartnerAccessToken -RefreshToken $refreshToken -Resource https://management.azure.com/ -Credential $credential -ServicePrincipal -TenantId <TenantId>
$graphToken = New-PartnerAccessToken -RefreshToken $refreshToken -Resource https://graph.microsoft.com -Credential $credential -ServicePrincipal -TenantId <TenantId>

Connect-AzAccount -AccessToken $token.AccessToken -GraphAccessToken $graphToken.AccessToken -TenantId <TenantId>

Please note the New-PartnerAccessToken command is part of the Partner Center PowerShell module.

[slavizh]

@IsaiahWilliams Thank you! On a first simple test it seems to work. For Connect-AzAccount you also need to provide AccountId parameter with the value of the application ID. I will give more extensive tests tomorrow.

[Phydeauxman]

@slavizh @jseerden thanks for the comments and concerns over this issue. One thing I want to make sure is noted is that we are working to convert as much as the previous functionality from AzureRM to the Az module, but we are limited in some aspects due to the new target framework (.NET 4.5.2 --> .NET Standard 2.0). One place where this affects us is the use of the Active Directory Authentication Library (ADAL) -- moving to a version of ADAL that supports the new target framework has resulted in a couple of changes that you may have noticed when using the previous AzureRM.Netcore module or the new Az module:

(1) There is no interactive login -- when running the command Connect-AzAccount with no additional parameters, rather than being prompted by UI to provide the username and password of the account you want to authenticate with, you instead see the device code login, which asks you to open the provided URL in a browser and provide the given code, which will then authenticate you as normal. Since ADAL doesn't support this UI prompt that was previously seen, the device code login is now the default login mechanism for the Az module; however, we do have plans to support our own interactive login in an upcoming release.

(2) Username and password is not supported -- back to the issue at hand 😀 currently, ADAL does not support username and password authentication, which is why we removed the -Credential parameter from being provided outside of the service principal parameter set for Connect-AzAccount in the AzureRM.Netcore module (which can now be seen in the Az module). From ADAL's wiki page, you can see the note on how this authentication scenario is not recommended, as well as how you can only get the token from this authentication in .NET Framework.

Side note: if you're interested in what forms of authentication will and won't work in ADAL against different frameworks, they provided tables for public client applications and confidential client applications that I'd recommend checking out.

Moving forward, where applicable, we recommend moving away from the username/password form of authentication and creating a service principal with the proper permissions that you will need to run the same script that you're looking to run with your account (or the account whose credentials you were previously providing). As mentioned in the links above, this is safer than using the username/password authentication and is a mechanism that is supported by the ADAL library on both target frameworks. I will need to get back to you on the CSP scenario, since you mentioned that you are unable to use service principals in that case.

Please let me know if you have any questions or comments!

While I agree with the Service Principal perspective...what about if you were storing the Service Principal properties (App ID, Key) in Key Vault and needed to retrieve them? If the authentication piece was there like it was before, you could authenticate with your user account (which might only have permissions to read a Key Vaults secrets), retrieve the Service Principal secrets and then use them to authenticate the Service Principal.

[slavizh]

@Phydeauxman Thank you for the clarification but we are aware of this. As CSP we just do not have any other choice than to use User Credential. I have explained the how CSP and the CSP scenarios to multiple people inside Microsoft. It is key to understand CSP to understand our problem. So far only @IsaiahWilliams has provided meaningful resolution to the issue (yet to test it fully though). If that resolution works it might be good idea to implement cmdlet in Az that we can get Refresh Token the same way we do it with Partner Center module. This is just to avoid relaying on Partner Center module when we want to use only Az module. I cannot speak for the other that are affected by those changes but I can say we do not have problem with using Service Principal as long as we can manage this easily at scale (as a CSP it is not easy to have service principal for each tenant for each solution in their Azure AD) and as long as there is Service Principal support for CSP (which there isn't as we get access to tenants via group called AdminAgent that allows only user members). So in first to use service principals at all the above needs to be solved. The above are also short description of the problems and when unfold more things to fix appear. To answer your question what would be the benefit of storing service principal properties in Key Vault if I have to login to that Key Vault via User Credentials (assuming that I need to do interactive login due to the issues with Connect-AzAccount)? We are trying to automate a process without any manual prerequisites that needs to be executed. Also I would prefer to take my Service Principal properties from any service that allows me to get them securely, not only via Key Vault. As summary I think overall it is really import to understand CSP and our CSP scenarios. I've also have been on a few meetings with different team members in Microsoft trying to explain the problems and find a solution for CSPs that is a long term one and fits into CSP scenarios.

[Phydeauxman]

@slavizh understand...just seems like a major step back from where we were with the AzureRm module. As far storing Service Principal info in Key Vault, I can configure the Key Vault access permissions to only allow specific accounts to be able to Read secrets that would enable them to run code using the Service Principal. Obviously, there is someone with elevated permissions that has to initially set this up but once setup it works great.

[slavizh]

@Phydeauxman Ok. Correct me if I am wrong but I will setup Key Vault. I will setup the permissions on the Key Vault. Will add Service Principal properties as secret. To get these properties from my automation workflow I will need to authenticate to the Key Vault first and if I try to do that with User Credentials I will not be able to do it non-interactively, correct? Our automation workflow is GitLab CI/CD so it does not have and specific integration like in Azure DevOps.

It is step back but the decisions for this change and the change itself (deprecating non-interactive user credentials) was made without nobody thinking about CSP scenarios and to be blunt on this: it is not the first time this happens. I've been finding specific features or services that do not work for CSP and every time I had to explain that there is another thing besides EA.

[slavizh]

@IsaiahWilliams I've resumed some testing today but to my surprise the thing that was working two days ago does not work. No idea why. I can get access token and graph token and for Tenant ID I am specifying the ID of the customer. When I try to use Connect-AzAccount I get error:

Connect-AzAccount : Exception has been thrown by the target of an invocation.

I even tried specifying the tenant ID of the partner when I get the tokens but still the same error when I use the Az command for login. Have you seen this error? Do you have it as well? If use fake values fro the tokens in Connect-AzAccount the command is execute successfully although when I try to execute another Az command I get information that access token is invalid. This is expected of course. But why is giving those errors when I have valid tokens.

[markcowl]

@slavizh If you set $DebugPreference="Continue" before execution and and Resolve-AzError after the error, you will get a bit more information - normally this would mean that there was an issue in listing subscriptions in the tenant.

FYI - the username/password fix is checked in and will be released later today or tomorrow. If you are still seeing this issue with token authentication, please file an issue and we will address it.

[markcowl]

This is relaesed now. Closing. @slavizh If you are seeing an issue (you should use the service principal id as the AccountId when logging in with tokens), please open a new issue.

[slavizh]

@markcowl Thanks! Will try to do more tests before I log an issue for that. I want to make sure if it is actual Az/AzureRM issue or I am doing something wrong.

[claudio-ss]

@markcowl Thank you, it works with the new Az.Accounts 1.2.0 Version.
$cred = Get-Credential
Connect-AzAccount -Credential $cred -Tenant $TenID -Subscription $SubID

[despian]

@markcowl I'm seeing the same issue as @slavizh when trying to run this command.

Connect-AzAccount -Credential $credentials -TenantId "xxx"
Connect-AzAccount : Exception has been thrown by the target of an invocation.

Looking at the debug output as you suggested this seems to be the pertinent error.

Message : Attempted to access an element as a type incompatible with the array.
StackTrace : at System.Collections.Generic.List'1.Add(T item)
at Microsoft.Azure.Internal.Subscriptions.SubscriptionClient.Initialize()
at Microsoft.Azure.Internal.Subscriptions.SubscriptionClient..ctor(Uri baseUri, ServiceClientCredentials credentials, DelegatingHandler[] handlers)

Like you said it appears to be related to listing subscriptions but I'm unsure how to resolve this.

Edit: Just FYI we are a CSP and I'm trying to connect to one of our customer's tenants.

[ghost]

Hi @despian,

I have not been able to reproduce the error that you are encountering. Would it be possible for you to run the command again, and then share the output from?

$Error[0] | fl -Force *

I believe that you are encountering this issue due to a configuration issue with the Azure AD application you used to request the access token.

[despian]

@IsaiahWilliams thanks for taking a look.

Here is the output you requested

writeErrorStream      : True
PSMessageDetails      : 
Exception             : System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArrayTypeMismatchException: Attempted to access an 
                        element as a type incompatible with the array.
                           at System.Collections.Generic.List`1.Add(T item)
                           at Microsoft.Azure.Internal.Subscriptions.SubscriptionClient.Initialize()
                           at Microsoft.Azure.Internal.Subscriptions.SubscriptionClient..ctor(Uri baseUri, ServiceClientCredentials credentials, DelegatingHandler[] handlers)
                           --- End of inner exception stack trace ---
                           at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
                           at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
                           at Microsoft.Azure.Commands.Common.Authentication.Factories.ClientFactory.CreateCustomArmClient[TClient](Object[] parameters)
                           at Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient.TryGetTenantSubscription(IAccessToken accessToken, IAzureAccount account, IAzureEnvironment 
                        environment, String tenantId, String subscriptionId, String subscriptionName, IAzureSubscription& subscription, IAzureTenant& tenant)
                           at Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient.Login(IAzureAccount account, IAzureEnvironment environment, String tenantId, String 
                        subscriptionId, String subscriptionName, SecureString password, Boolean skipValidation, Action`1 promptAction, String name, Boolean shouldPopulateContextList)
                           at Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand.<>c__DisplayClass92_0.<ExecuteCmdlet>b__0(AzureRmProfile localProfile, RMProfileClient 
                        profileClient, String name)
                           at Microsoft.Azure.Commands.Profile.Common.AzureContextModificationCmdlet.ModifyContext(Action`2 contextAction)
                           at Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand.SetContextWithOverwritePrompt(Action`3 setContextAction)
                           at Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand.ExecuteCmdlet()
                           at Microsoft.WindowsAzure.Commands.Utilities.Common.AzurePSCmdlet.ProcessRecord()
TargetObject          : 
CategoryInfo          : CloseError: (:) [Connect-AzAccount], TargetInvocationException
FullyQualifiedErrorId : Microsoft.Azure.Commands.Profile.ConnectAzureRmAccountCommand
ErrorDetails          : 
InvocationInfo        : System.Management.Automation.InvocationInfo
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {0, 1}

I'm not actually using application access but plain user creds as described here:

https://docs.microsoft.com/en-us/azure/cloud-solution-provider/overview/azure-csp-management-options#powershell

[despian]

@IsaiahWilliams just FYI it's now working for me.

I finally got round to increasing the disk size on my Win 10 VM and installing the creators update. After that, it just worked. I thought I had the latest PS related updates but seems maybe not.

[slavizh]

As I haven't logged separate issue I would like to provide some update on this error:

Connect-AzAccount : Exception has been thrown by the target of an invocation.

Seems Az and Partner Center modules are having co-existence issue caused by assembly 'Newtonsoft.Json. I have addressed the issue to see if this is a bug in Az or PartnerCenter module. There is also this topic that seems related:
PowerShell/PowerShell#2083

Apologies that I am posting comment on an issue that is closed and the comment is not exactly for this issue.

[ghost]

Hi @slavizh,

Thank you for sharing that link to the active issue with PowerShell. The next release of the Partner Center PowerShell module will resolve this issue. We are making the version of Newtonsoft.Json match what the Az module is using. Long term we are investigating alternative plans to avoid any potential issues caused by dependency versions not matching.