Error building AzureRM Client: No (unexpired) Authorization Tokens were found (User credentials)

[arcotek-ltd]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.11.10
+ provider.azurerm v1.19.0

Affected Resource(s)

All

Terraform Configuration Files

NA

NA

Debug Output

Gist

Expected Behavior

Erm, show plan?

Actual Behavior

Error: Error refreshing state: 1 error(s) occurred:

* provider.azurerm: Error building AzureRM Client: No (unexpired) Authorization Tokens were found - please re-authenticate using `az login`.

Steps to Reproduce

1. terraform plan -var-file="shrg.tfvars"

Important Factoids

I am authenticating using my user account as opposed to a service principal. It was working and now it's not. I have deleted .terraform.

What caused my issue was to install the new AZ PowerShell cmdlets, which I presume, interferes with the already-installed AZ CLI. I am waiting for Microsoft to respond here. My AZ CLI is now broken and uninstall / reinstall does not fix AZ CLI.

If we assume that the AZ PowerShell cmdlets install is to blame, then I believe there is a difference in the token that is generated, and my suspicion is that Terraform cannot handle this token. The log suggests that the token has expired, but it has not.

New AZ PS cmdlets that I run to authenticate:

Remove-AZAccount #Get rid of any tokens that may exist.

Login-AZAccount #Use web browser, pasting in code generated on cmdline

Set-AZContext -SubscriptionName "MySubscription"

Get-AZContext #Only "MySubscription", authenticated as my user is return

I know I'll be told to use the SP, and we do in production, but this is for quickly testing, without dropping AD application credentials that run the risk of ending up in VCS. The point is that AZ CLI works but the new AZ PS cmdlets do not. I am sure it's a small issue with the token format.

In addition, MS are replacing the old AzureRM PS cmdlets with AZ PS and if indeed AZ CLI and AZ PS cannot coexist then this will break TF AZ CLI authentication.

References

• #0000

[tombuildsstuff]

hi @arcotek-ltd

Thanks for opening this issue :)

Taking a quick look into this it appears would be a duplicate of #502 - essentially Terraform can't refresh the access token since we don't own that file (and thus don't want to break the Azure CLI). Out of interest - does this work if you logout and then log back in using the Azure CLI?

Thanks!

[arcotek-ltd]

Hi @tombuildsstuff,
Thanks for your reply. I understand what you are saying and it's a good plan (no pun intended). I realised this is what you do because I couldn't authenticate against a particular subscription as user 'X'. Looking at the logs, I saw I was still logged in as user 'Y', even though I had run az login.

In this instance, I am (hopefully) clearing the token and logging out of Azure, with the Remove-AzAccount (equivalent of az account clear) and then creating a new token, which according to TF has expired, yet it was created within a minute of running terraform plan...

As I said, my immediate thought is that there is a slight difference in the token generated, between AZ CLI and AZ PS. I don't know enough to prove that theory, but I can run AZ commands against Azure after logging in, using the method detailed above.

Thanks again

[tombuildsstuff]

hey @arcotek-ltd

Thanks for getting back to us here. Whilst there may be variations between the Azure CLI and Azure PowerShell - unfortunately the Azure PowerShell isn’t supported (we only support v1/v2 of the Azure CLI at this time) - as such we can’t provide support for this. It’s possible that PowerShell may be storing the timezone differently to the Azure CLI (and as such it may be possible to work around this by setting the relevant environment variable) - however since this isn’t officially supported (and we have no plans to support this) I don’t think there’s much we can do here.

Instead it should be possible to achieve this using the Azure CLI (or as you’ve mentioned a service principal) - which are the main supported authentication methods at this time. As this issue is about functionality we have no plans to support (since it’s possible to achieve this using the Azure CLI) - I’m going to close this issue for the moment.

Thanks!

[arcotek-ltd]

Mmm. It will be interesting to see what happens when MS pull support for AzureRM modules and people start to install AZ PS which then breaks Azure CLI and thus TF.

Thanks for the help!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!