User-assigned managed identity regression in Az.Accounts 2.1.0

Resolved: see “Update 2020-11-02” below"

Before Az.Accounts 2.1.0, user-assigned managed identities could be used in PowerShell Functions like this:

Connect-AzAccount -Identity -AccountId <guid>

Starting from Az.Accounts 2.1.0, the same code reports the following error:

ManagedIdentityCredential authentication failed: Service request failed.

Workaround

The workaround is to pin your Az.Accounts to the previous working version (1.9.5).

Method 1: Editing requirements.psd1

• Remove the Az module entry from requirements.psd1.
• Add the following line to requirements.psd1:

@{
    ...
    'Az.Accounts' = '1.9.5'
    ...
}

• At the beginning of profile.ps1, invoke:

Import-Module Az.Accounts -RequiredVersion '1.9.5'

The last step is necessary because installing other Az.* modules may automatically install higher versions of Az.Accounts, and this is what PowerShell may load by default.

Method 2: Include the desired module versions into the app

• Include Az.Accounts module (and other modules, if desired) content into the app directly (see Function app-level Modules folder). Make sure there is no version of Az.Accounts higher than 1.9.5.
• Remove the references to these modules from requirements.psd1.

Please note that modules included into the app directly are never auto-upgraded by Managed Dependencies automatically.

Update 2020-11-02

The regression is fixed in Az.Accounts 2.1.2, which is published to the PowerShell Gallery now. The workaround described above is not required anymore.

The newly deployed apps that depend on Az (without specifying exact Az.Accounts versions) will work as they used to work before.

The existing apps that already happened to pick up Az.Accounts 2.1.0 will self-heal automatically in the next Managed Dependencies update cycle (by default, within 1-7 days - for more details, see the relevant Function app settings documentation). If you want to ensure the fix is applied sooner, please add the following entry to requirements.psd1:

@{
    ...
    'Az.Accounts' = '2.1.2'
    ...
}

In the future, if you want to make sure Az.Accounts is pinned to any specific version, please be aware that the dependencies between Az.Accounts and other Az.* modules are configured like this (see Package Details on the PowerShell Gallery):

Az.Accounts (>= 1.7.5)

As a result of this, installing older versions of Az will always bring in the latest version of Az.Accounts. For example, the following command:

InstallModule -Name Az -RequiredVersion 3.8.0

will install Az.Accounts 2.1.2 now. In the future, exactly the same command will install a newer version of Az.Accounts. This is exactly what’s happening in Azure Functions as well, and this is why pinning just the Az module version is not enough. If you must pin Az.Accounts to any specific version, the original workaround described above is still required.

[TylerLeonhardt]

I just wanted to also add that I experienced issues with Connect-AzAccount -Identity using System assigned MSI with the latest version of Az.Accounts (2.1.2)

[simonesavi]

I faced the same problem. There is a solved bug in Az.Accounts 2.1 (here)

To avoid the problem it can be used the requirements.psd1 with follow configuration:

@{
    'Az'           = '4.8.0'
}

This version contains Az.Accounts 1.9.5

I have also found that if you previously used the Az.Accounts module v2.1.0, the downgrade isn’t automatic. I believe this happen because function download the decencies once at startup. For this it is required to specific which version of Az.Accounts module to use. If it’s possible, try a fresh deployment of function with Az version 4.8.0.

@ChendrayanV I suggest to you to remove the version 2.1.0 because it contains an authentication issues, and in the correct conditions it could potentially stop to work.