Get-Command -Module AzureRM.Profile. You're seeing it correctly - it doesn't have a Logout-AzureRmAccount, Disconnect-AzureRmAccount, Remove-AzureRmAccount or even Remove-AzureRmContext commandlets! That's a lot of fun :)

Oh no! PowerShell cached my Azure credentials and I messed up wrong customer’s environment!

This post was most recently updated on February 4th, 2019.

Whoops. Could happen to anyone, since the Azure PowerShell since (approximately) version 6.3.0 will cache your credentials between sessions without warning you. It’s really easy to run your commands with cached accounts, and end up executing your scripts against the wrong environment.

In less serious cases, this means that you’ll end up running commandlets twice against the test environment, while you think you’re running them first against test, and then production. In more serious cases, you’ll deploy your ARM templates or run your cleanup scripts against wrong customer’s environment.

Root cause for the issue

What Microsoft says themselves:
In versions 4.4.0 and later (see https://github.com/Azure/azure-docs-powershell/blob/master/docs-conceptual/azurermps-5.7.0/context-persistence.md for more info), it’s been possible to cache your context. In some later version (probably 6.3.0) Microsoft flipped the switch to enable this by default – so now Azure PowerShell retains your context information automatically between sessions.

This means, that if you were running some AzureRM commandlets against Customer X’s environment, then shut down your machine for the night, and start running commandlets against Customer Y’s environment, you might use the context from yesterday – X’s environment.

I’ve done this. That meant I was provisioning new Azure artefacts into the wrong customer’s environment. Ouch..

So the way this has been implemented, is that Azure PowerShell offers a feature called Azure Context Autosave, which gives the following features:

  • Retention of sign-in information for reuse in new PowerShell sessions.
  • Easier use of background tasks for executing long-running cmdlets.
  • Switch between accounts, subscriptions, and environments without a separate sign-in.
  • Execution of tasks using different credentials and subscriptions, simultaneously, from the same PowerShell session.

So with Any AzureRM version after 4.4.0 you might be in danger, and for versions after 6.3.0 you’re definitely in danger of using this functionality in an unexpected manner. :)

To see which version you’re using, run this:

Get-Module AzureRM -ListAvailable

But what does this feature mean in practice? In short, if you run certain commandlets (like Add-AzureRmAccount) while it already has a cached account, it will use the cached one instead of the one you’re offering it.

Yeah, sounds unintuitive and kind of dangerous, but the intention was to make your life easier. Paving the way to hell and all that… 

In short: it’s not a bug, it’s a feature.

A feature, that’s been a bit of a pain to at least yours truly. But how to work around it?

Solution: Reset your Azure Remote Management Context

Okay, you probably don’t want to use the cached credentials when changing between customer environments. You’ll want to instead get rid of the cached credentials – but that can’t be done super easily

This solution presumes, that you already have AzureRM commandlets imported.

Running this shows you your current Azure Context:

Get-AzureRmContext

That one shouldn’t return anything when you open up a new session – but it sometimes does. And this might catch your scripts off-guard!

For initializing your context, especially in scripts that you’re distributing to someone else, it might be worthwhile to set your context to an empty one before your script creates one. This commandlet will nullify the cached context by overwriting it with a new, empty one:

Set-AzureRmContext -Context ([Microsoft.Azure.Commands.Profile.Models.PSAzureContext]::new())

How to stop PowerShell from caching your credentials in the future?

Additionally, to disable this feature in the future, run this:

Disable-AzContextAutoSave

With that, you should be good. Just relaunch PowerShell, and cache should be gone!

Sources and further reading

The following two tabs change content below.
mm

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Leave a Reply

avatar
5000
  Subscribe  
Notify of