This post was most recently updated on March 28th, 2023.
3 min read.
Whoops. This could happen to anyone since the Azure PowerShell (approximately) version 6.3.0 will cache your credentialsbetween sessionswithout 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 the test, and then production. In more serious cases, you’ll deploy your ARM templates or run your cleanup scripts against the wrong customer’s environment.
The root cause for the issue
What Microsoft says:
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
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.
Time needed:5 minutes
Reset your Azure Remote Management Context
- This solution presumes, that you already have AzureRM commandlets imported.
Running this shows you your current Azure Context:
<pre lang="powershell">Get-AzureRmContext
</pre>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:
<pre lang="powershell">Set-AzureRmContext -Context ([Microsoft.Azure.Commands.Profile.Models.PSAzureContext]::new())
</pre> - Additionally, to disable this feature in the future, run this:
<pre lang="powershell">Disable-AzureRmContextAutosave</pre>
- With that, you should be good. Just relaunch PowerShell, and the 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
- https://docs.microsoft.com/en-us/powershell/azure/context-persistence?view=azps-1.0.0
- https://github.com/Azure/azure-powershell/pull/6003
- https://stackoverflow.com/questions/34180738/azure-powershell-what-is-the-opposite-command-to-login-azurermaccount-used-to
- https://github.com/Azure/azure-powershell/pull/6003
- 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)
- https://www.cloudfronts.com/azure-console-login-logout-using-azure-powershell/
- Author
- Recent Posts
Antti K. Koskela
Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd
Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.
He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.
This is his personal professional (e.g. professional, but definitely personal) blog.
Latest posts by Antti K. Koskela (see all)
- How to generate Certificate-Signing Requests using OpenSSL - June 18, 2024
- Home Assistant 2024.4 changes weather forecasts – what to do? - June 11, 2024
- External path “**” cannot have more than one “*” wildcard with vite? - June 4, 2024
00votes
Article Rating
Posts Related to "Oh no! PowerShell cached my Azure credentials and I messed up wrong customer's environment!":
- How to access Entity Framework Core's DbContext in an Azure Function?
- swa emulator throwing "✖ Could not connect to "http://localhost:7071". Is the server up and running?"?
- Another fix to the "Connect-PnPOnline : The sign-in name or password does not match one in the Microsoft account…