[BUG]: AzureCLI@2 az login fails when using certificate for authentication starting from version 2.67.0 of Azure CLI

[jan-msc]

Starting from version 2.67.0, for az login, --password no longer accepts service principal certificate. Use --certificate to pass a service principal certificate.
AzureCLI@2 does not use the --certificate parameter to pass the service principal certificate resulting in:
ERROR: AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app '***'. The error may be caused by passing a service principal certificate with --password. Please note that --password no longer accepts a service principal certificate. To pass a service principal certificate, use --certificate instead.

[NakagawaMakoto]

I am experiencing the same issue. Is there any way to downgrade azure cli to prior version?

[jan-msc]

@NakagawaMakoto : Azure CLI has no downgrade functionality but you can uninstall it and install the desired version (2.66.0) instead.

[NakagawaMakoto]

Yes, of course, it is me who is responsible for the version of azcli on the pipeline agent's host. I should have known better. Thank you for reminding me of the fact.

[RichieBzzzt]

To work around this issue we added this step to our builds. Would love to see the issue fixed though!

    apt-get remove -y azure-cli
    apt-get install -y azure-cli=2.66.0-1~focal```

[mhever]

This is breaking user pipelines on our side, this should be fixed asap.

[vi7us]

As a workaround, adding this task should help on windows host

 - powershell: |
    wmic product where "name='Microsoft Azure CLI (64-bit)'" call uninstall /nointeractive
    Invoke-WebRequest -Uri https://azcliprod.blob.core.windows.net/msi/azure-cli-2.66.0-x64.msi -OutFile .\AzureCLI.msi; 
    Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet';
  displayName: Downgrade azure CLI

[robkendrick]

As a workaround, adding this task should help on windows host

• powershell: |
  wmic product where "name='Microsoft Azure CLI (64-bit)'" call uninstall /nointeractive
  Invoke-WebRequest -Uri https://azcliprod.blob.core.windows.net/msi/azure-cli-2.66.0-x64.msi -OutFile .\AzureCLI.msi;
  Start-Process msiexec.exe -Wait -ArgumentList '/I AzureCLI.msi /quiet';
  displayName: Downgrade azure CLI

Thanks for this--I wasn't having much luck with the msiexec.exe /x uninstaller! Unfortunately, it takes the Hosted Agents anywhere from six to fourteen minutes to complete the uninstall.

In the interim, I've added Federated Credentials to the App Registration in Entra ID, then associated that with a new Service Connection in AzDO, and that works with no issues--pipelines are back to being speedy. The great part about this method (thus far) is that because it's the same AppID it uses the same Service Principal (Enterprise Apps in EID), so you don't have to go update the RBAC for every resource.

For those who haven't done this before, here's a quick rundown of how to do it:

1. Go to your Service Connections under Project Settings (can also just use the standard URI: https://dev.azure.com/<orgName>/<projectName | projectID>/_settings/adminservices)
2. Click [ New Service Connection ] -> Azure Resource Manager -> [ Next ] -> Workload Identity federation (manual) -> [ Next ].
3. Give the Service Connection a name that is distinctive from the existing version of the service principal.
   • I would advise naming it something that indicates they're related (e.g.: original is "ServiceConnection-Dev-Certificate", make this one "ServiceConnection-Dev-Federated"). Tick/enable "Grant access permission to all pipelines" only if needed, then click [ Next ].
4. Leave that tab as-is because you'll need the provided Issuer and Subject Identifier values. Open a new tab, then go to AAD/EID.
5. Go to your App Registration for the existing Service Connection (or a new one if you decide to go that route), then click on the Manage -> Certificates & secrets Blade.
6. Click Federated Credentials, then + Add credential.
7. Enter/Select the following:
   a. Federated credential scenario: Other
   b. Issuer: Enter the Issuer from the AzDO Service Connection in the previous tab.
   c. Subject Identifier: Enter this value from the AzDO Service Connection.
   d. Give the credential a name.
   e. Click [ Add ].
8. Click the Overview blade on the left and then copy/save/notate the "Application (client) ID" for this App.
9. Go back to the AzDO tab and finish setting up the Service Connection--remaining instructions assume a scope of "Subscription."
   a. Service Principal ID is the AppID copied from Step 9.
   b. Subscription ID and Name can be found easily on the Subscriptions blade.
   c. Tenant ID can be quickly pulled from the directory listing.
10. Click [ Verify and Save ].
11. Update your pipelines with the new Service Connection name and test.

[KKing299]

@robkendrick - What you said is partially a workaround. It doesn't work out for MSPs since one app registration can only have 20/30 federated credential. Whenever you create a service connection it will take up one federated credential. Let's say if someone wants to manage multiple tenants then it wouldn't work because of restriction on the number of federated credential an app registration can have.
@v-schhabra Does MS have any updates? This needs to be fixed ASAP! This is breaking production setup

[v-schhabra]

Hi @KKing299
The issue has been fixed in this PR #20698
#20701
Please let us know if you are having any issues.

[v-schhabra]

Hi @KKing299
please share the latest updates.