Stop typing PowerShell credentials in demos using PowerShell SecretManagement

We all sometimes create presentations with some PowerShell demos. And often, we need to use credentials to log in to systems for example PowerShell when delivering these presentations. This can lead that we don't use very strong passwords because we don't want to type them during a presentation, you see the problem? So, here is how you can use the PowerShell SecretManagement and SecretStore modules to store your demo credentials on your machine.

Doing this is pretty simple:

Install the SecretManagement and SecretStore PowerShell modules.

Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore

Register a SecretStore to store your passwords and credentials. I this example we are using a local store to do that. Later in this blog post, we will also have a look at how you can use Azure Key Vault to store your secrets. This is handy if you are working on multiple machines.

Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

Now we can store our credentials in the SecretStore. In this example, I am going to store the password using, and I will add some non-sensitive data as metadata to provide some additional description.

Set-Secret -name DemoAdmin01 -Secret "demoAdmin01PassWord" -Metadata @{demo = "My Hyper-V demo for Windows Server and Linux Remoting"}

You can also store other data types like PSCredential in SecretManagement. For this example, I am using just a simple string, because this works for most scenarios. 

PowerShell SecretManagement supports the following secret data types:

  • byte[]
  • string
  • SecureString
  • PSCredential
  • Hashtable

Store Secret in PowerShell SecretStoreStore Secret in PowerShell SecretStore

Now you can start using this secret in the way you need it. In my case, it is the password of one of my admin users. 

$DemoAmdin01secret = Get-Secret -Vault SecretStore -Name DemoAdmin01
$DemoAmdin01Cred = New-Object -TypeName PSCredential -ArgumentList "DemoAdmin01", $DemoAmdin01secret

As mentioned before, you can also store a PSCredential object directly in SecretManagement if that makes it easier for you.

These two lines, I could also store in my PowerShell profile I use for demos, or in my demo startup script. In this case, the credential object is available for you to use.

Use SecretStore crednetialsUse SecretStore crednetials

If you are using multiple machines and you want to keep your passwords in sync, the Azure Key Vault extension.

Install-Module Az.KeyVault
Register-SecretVault -Module Az.KeyVault -Name AzKV -VaultParameters @{ AZKVaultName = $vaultName; SubscriptionId = $subID}

Now you can store and get secrets from the Azure Key Vault and you can simply use the -Vault AzKV parameter instead of -Vault SecretStore. 

I hope this blog provides you with a short overview of how you can leverage PowerShell SecretManagement and SecretStore, to store your passwords securely. If you want to learn more about SecretManagement check out Microsoft Docs.

I also highly recommend that you read @Pierre Roman blog post on leveraging PowerShell SecretManagement to generalize a demo environment.

This is really cool use case for it 🙂 Thanks for sharing!!!

Happy Azure Stacking!!!

Nice, qurestion this local vault is register on user account or all Admins of machnie can access to vault or is there some ACL who can access ?

Can this be used with scripting to avoid situations where username/password has to be stored in a restricted text file (i.e. when it's not possible to use a service account)?

Also have a similar question as @ChuckFinley 

From a quick review of this, if I am going to use this in I still need to to keep the Vault password somewhere, i.e in a XML document. What has been missed from this document is that if you open up a fresh PowerShell window, when you run the first Get/Set-Secret it asks for a password.

@thomasmaurer – Thoughts around using this when you have a “scheduled task” machine running your ?


This article was originally published by Microsoft's Networking Blog. You can find the original article here.