This post was most recently updated on October 8th, 2019.Reading Time: 3 minutes.
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
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:
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:
With that, you should be good. Just relaunch PowerShell, and cache should be gone!
Note: The snippet above used to say “Disable-AzContextAutoSave”. That’s a valid command as well, but for Azure PowerShell (instead of Azure RM commandlets).
Sources and further reading
- http://itproguru.com/expert/2015/03/how-to-remove-azure-accounts-cached-credentials-from-powershell-remove-azureaccount-for-all-accounts-step-by-step/ (doesn’t seem valid for any newer cmdlet versions, but I’m saving this anyway)
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.
Latest posts by Antti K. Koskela (see all)
- Azure DevOps – how to package a simple DLL? - October 17, 2019
- How to use UriHelper or NavigationManager in .NET Core 3.0 & Blazor? - October 17, 2019
- Azure DevOps build fails with “The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages.” - October 16, 2019