Stop typing PowerShell credentials in demos using PowerShell SecretManagement

Published Apr 14 2021 04:02 AM 28.3K Views

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 credentialsUse SecretStore credentials


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.


Want to learn how to install PowerShell 7? Check out my video on Microsoft Channel 9.



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

Senior Member

This is really cool use case for it :) Thanks for sharing!!!


Happy Azure Stacking!!!

Occasional Contributor

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 ?

Occasional Visitor

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)?

New Contributor

Also have a similar question as @ChuckFinley 


From a quick review of this, if I am going to use this in automation 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 scripts?


@ChuckFinley Yes, absolutely! 


@NMLVS Yes, so there is an example in the announcement blog, let me quote that part here:


Using the SecretStore in Automation

This is an example of automation script that installs and configures the Microsoft.PowerShell.SecretStore module without user prompting. The configuration requires a password and sets user interaction to None, so that SecretStore will never prompt the user. The configuration also requires a password, and the password is passed in as a SecureString object. The -Confirm:false parameter is used so that PowerShell will not prompt for confirmation.

The SecretStore password must be provided in a secure fashion. Here the password is being imported from an encrypted file using Windows Data Protection API, but this is a Windows only solution. Another option is to use a CI system mechanism such as secure variables.

Next, the SecretManagement module is installed and the SecretStore module registered so that the SecretStore secrets can be managed.

The Unlock-SecretStore cmdlet is used to unlock the SecretStore for this session. The password timeout was configured for 1 hour and SecretStore will remain unlocked in the session for that amount of time, after which it will need to be unlocked again before secrets can be accessed.


Install-Module -Name Microsoft.PowerShell.SecretStore -Repository PSGallery -Force
$password = Import-CliXml -Path $securePasswordPath

Set-SecretStoreConfiguration -Scope CurrentUser -Authentication Password -PasswordTimeout 3600 -Interaction None -Password $password -Confirm:$false

Install-Module -Name Microsoft.PowerShell.SecretManagement -Repository PSGallery -Force
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault

Unlock-SecretStore -Password $password



@Michal Machniak There is also a SecretStore Scope setting, but it is currently set to CurrentUser and cannot be changed.

If you need to sync passwords between multiple users, you could register the Azure Key Vault for every user as an SecretStore

Occasional Visitor

Hey @thomasmaurer,


Thanks for sharing great content. Can you share what color theme you are using for your terminal?

Version history
Last update:
‎May 16 2021 06:59 AM
Updated by: