Azure-cli: Azure Portal generated passwords with special characters not accepted by az login service principal

[michaeldeongreen]

Describe the bug
When trying to use a Service Principal password that contains special characters, you get errors (see screenshot attachment)

To Reproduce
See screenshot attachment

Expected behavior
I am able to login via az login if the correct credentials are supplied

Environment summary
latest version of azure-cli, just installed it (2.0.52) and running the commands via Windows Powershell

Additional context
The passwords are being generated in the Azure Portal when I create a secret, so I have no control over how the password gets generated. Would be nice to have an option to specify if special characters are placed in the password or not ie passwordgenerator.net.

See attached to view all the different combinations I have tried with no success. As you can see in the last attempt, I put the wrong password in ("test"), which has no special characters and authentication failed, which tells me it is the password format that is the issue.

Also, I generated about 10 different secrets and all have special characters and would not work.

[twoo]

same issue, tried '', "", @""@, nothing works.

[tjprescott]

The reason is because you are using Powershell and need to format your password string accordingly. From your screenshot, you can see that $? is being interpreted by the shell (that's why it appears green). Additionally, the & character is being interpreted by Powershell as the start of a new command.

Unfortunately, shell-specific processing occurs before the CLI is ever invoked, so we cannot control this behavior. The escape character in powershell is the backtick ` so you might try that. Alternatively, I tested these strings in CMD.exe and bash and they work (though in bash you probably need the outer quotes to be single instead of double).

[Zerg00s]

Similar issue with the & character:
When running this from PowerShell:

az login -u "[email protected]" --allow-no-subscriptions -p "Pass_&_AY"

Error:
'_AY' is not recognized as an internal or external command,

Escaping & with a backtick does not help.

[Zerg00s]

Found a workaround that works in PowerShell:

$o365Admin = Get-Credential -Message "Enter Global Office 365 Admin Credentials"
az login -u $o365Admin.UserName --allow-no-subscriptions -p "`"$($o365Admin.GetNetworkCredential().password)`""

[joshschmitter]

@tjprescott I think @Zerg00s workaround (which also works for me) is evidence that you've misdiagnosed the issue. The shell-specific interpolation is of course out of your control, but if that were the only problem with the OP's examples, wrapping the password in single quotes should have succeeded.

What @Zerg00s did to get it to work was double-wrap the password in quotes (escaping the inside set of quotes). So the value ends up being "`"$password`"" (this is exactly how I passed in the value to get it to work). This shows that the az cli is doing extra interpolation after receiving the string, which it shouldn't be doing.

[joshschmitter]

Hi @tjprescott, I don't think this issue should be closed. See my comment above. Could you please re-open it?

[tjprescott]

I'm no longer on the CLI team, so I can't re-open. @MyronFanQiu can you take a look and re-open if appropriate?

[MyronFanQiu]

@jiasli Please take a look.

[jiasli]

Similar to https://github.com/Azure/azure-cli/issues/11003#issuecomment-569213105

@joshschmitter, please check the solution and let us know if you can get unblocked.

[joshschmitter]

Yeah, #11003 seems like the same root cause. And according to the docs referenced, this is happening because the az cli is a batch script and powershell has to pass the command to the Command Prompt. Using the stop-parsing symbol --% is inconvenient since variables like $password won't be interpolated, but it doesn't look like another solution is possible.

I think I'll keep escaping another set of quotes.

Thanks for the info.

[jiasli]

Windows PowerShell is aware of this issue and is working on a fix.

Currently if you need to use $password, special characters needs to be escaped according to CMD syntax to prevent it from being parsed again by CMD. Thanks for your understanding.

[fidelcoria-aa]

FWIW in bash using --pasword=<nasty password with ugly chars>
worked for me (i.e. using =)