Unlock the secrets to bulletproof password management in PowerShell! Discover how Microsoft's Secrets Management modules can transform your security practices, eliminate plaintext vulnerabilities, and streamline your automation scripts. Dive in now to secure your IT environment like a pro! 

What this article covers

Ask any IT professional what an important aspect of their job is, and security usually bubbles to the top of their list. Security takes many forms from credential management, software configuration, and protective services. In this article, we will cover securely using passwords with PowerShell, whether it is a single-use script or possibly an automated script, and specifically we will be covering Microsoft's Secrets Management modules.

Why use the PowerShell Secret Management module?

Malicious actors take many forms and they attack platforms used by IT professionals and organizations for a myriad of tasks. Exploits range from vulnerabilities in software and hardware to self-inflicted security holes like plaintext passwords in scripts. Reducing that attack surface should be on every administrator's list of tasks. The addition of Secrets Management can help elevate your password management mechanics. Let’s explore how we can do this.

Is it more secure?

Well, yes and no, said the IT Consultant. Using a vault isn't all about being more secure, but it is about keeping a central location for passwords. Let me explain.

Visual representation of the advantage of using Secrets Management over a single password file

To access a vault, we need to pass some sort of credentials to the vault. We could use a clear text password (well actually don't do that), perhaps we could use a password file (which we can do without a vault in scripts) or maybe there is a REST API call or XML file that needs to be accessed. All these methods have their weaknesses and strengths:

• Clear text password: BAD. This is a hacker’s dream, don’t do this.
• Password file: Using PowerShell to create, it only works on the local computer where it was created. It can be secured with NTFS and AD Group permissions.
• REST API: This will require a key of some sort generated and accessible by the script.
• XML File: See password file.

Without a vault, a 'secure' script will use a password file that is hashed by PowerShell and only accessible locally. With the secrets vault, we now have a one-to-many solution which allows access to a plethora of secrets or credentials vs just one at a time.

Where to start?

PowerShell SecretManagement module and SecretStore module

Like all things PowerShell, we need to first install the two required PowerShell modules and once installed, we will import them into a PowerShell session.

Install PS modules

Install-Module Microsoft.PowerShell.SecretManagement

Install-Module Microsoft.PowerShell.SecretStore

Import PS modules

Import-Module Microsoft.PowerShell.SecretManagement

Import-Module Microsoft.PowerShell.SecretStore

Cmdlets

Now that we have the modules installed and imported, we can review the cmdlets:

Microsoft.PowerShell.SecretManagement and Microsoft.PowerShell.SecretStore – Both modules have a limited number of cmdlets

Default vault storage

Create & configure a new vault

After loading the two modules as shown previously, we now need to register a vault to be used. In the below example, we are creating a local machine vault accessible for only the local user.

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

Once registered we need to set some configuration settings on the vault, the first of which is the password:

$Password = Import-CliXml -Path $securePasswordPath 

Then we set authentication parameters for accessing the vault:

$StoreConfiguration = @{  

    Authentication = 'Password'

    PasswordTimeout = 3600 # 1 hour 

    Interaction = 'None' 

    Password = $password 

    Confirm = $false 

} 

These settings are applied to the vault, and we now have a place to store credentials.

Set-SecretStoreConfiguration @storeConfiguration

Adding and removing secrets

Add

Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore

Set-Secret -Name M365GA01 -Secret "!@dF45#281*sdf" -Vault SecretStore

Remove

Remove-Secret -Name TestSecret -Vault SecretStore

Set-Secret -Name M365GA01- Vault SecretStore

Unlock and timeout

Use timeouts for the vaults, if at all possible, even for Automations. If your Automation takes too long (exceeds timeout) try to make the Automation more efficient. IF that fails, slightly extend the timeout to cover outside run times. While it is possible to use an open timeout with an Automation, this will expose the vault to attacks as it will be open indefinitely.

Default timeout

Get-SecretStoreConfiguration

As we can see, the default timeout is 900 seconds or 15 minutes

Extending or shrinking the timeout

Set-SecretStoreConfiguration -PasswordTimeout 1800

As shown above, changing the Timeout will need to be confirmed

Set-SecretStoreConfiguration -PasswordTimeout 450

When shortening the timeout, we will receive a similar message and we may also receive a prompt for the password to the vault itself.

Practical uses

In terms of practical uses, there are quite a few to pick from such as on-prem maintenance tasks, cloud resource scripting, and general automation across workloads. Each of these can utilize the vault as they depend on PowerShell authenticating with resources and then performing various tasks with the access provided. Let's walk through a couple of quick examples to show how to integrate secrets with scripts.

On-premises (example)

Ideally, for on-premises maintenance, administrators will have a regular user account and an elevated user account. Beyond these accounts, we might also have general service accounts or Group Managed Service Accounts (gMSA's). For this example, we will use a service account and utilize a PowerShell generated credential file for our process and this file is only accessible by an administratively created AD Group.

Prep work:

• Create password file

$Credential = Get-Credential -UserName 'SecureStore'

$PasswordPath = 'C:\data\password.xml'

$Credential.Password | Export-Clixml -Path $PasswordPath

• Create the vault

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

• Set password for the vault    

$Password = Import-CliXml -Path $PasswordPath

Unlock-SecretVault -Name SecretStore -Password $Password

• Access the vault

Unlock-SecretVault -Name SecretStore -Password $Password

• Add the secret

Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore

• Grab secret for script

$automationPassword = Get-Secret -Vault SecretStore -Name TestSecret

Use the secret in the vault to run the tasks at hand. Never use PlainText but make sure that the password is output as SecureString.

Note: Once the vault times out, it is locked, and we will not be able to query those credentials until it is unlocked again.

Sub-modules

We can work not only with local Windows Stores, but with additional sub-modules, we can work with other Secrets Stores. What if you already have a password vault? You may be in luck as Microsoft's Secrets Module does integrate with some of the more well-known players out there. Many organizations trust their password vaulting to vendors like Cyberark.

** These sub-modules are also typically created by non-Microsoft authors. Support may or may not exist and your support for using the module may vary.

Available modules

Find-Module SecretManagement.* | Sort Name



# Alternatively, use tag to find Extension Vaults

Find-Module -Tag SecretManagement. | Sort Name

List of sub-modules for secrets management that are available on PSGallery

Chrome browser (example usage)

Install and import the sub-module:

Install-Module SecretManagement.Chromium

Import-Module SecretManagement.Chromium

Register the vault so that the Secret Management module can work with the vault:

Register-ChromiumSecretVault -Preset Chrome

Query for any stored secrets that Chrome has stored on your local workstation:

Get-SecretInfo -Value Chrome

As shown above, this workstation has four stored credential sets in Chrome

Notice there are saved credentials for Microsoft services, Archive.Org, and Dominos, although Dominos seems to be incomplete. While this appears to be insecure, remember that all secret stores are under your profile and are unlocked using your credentials.

Note: We cannot remove a secret using this PowerShell module however.

Using PowerShell to remove a secret from the Chrome vault

However, if we cannot remove the passwords, what use is just pulling creds? Just like other vaults, we can query the credentials, store them in PowerShell, and use them with other operations/PowerShell cmdlets.

Note that this module only has two cmdlets:

Get-ChromiumError

Register-ChromiumSecretVault

The Get-ChromiumError cmdlet is only for displaying any errors that occurred while using the module. Make sure to check out the Readme.md - which can be found on the module's GitHub page.

CyberArk (example usage)

CyberArk is a popular security for organizations looking to secure their environment with the features it provides. One of these features is a Password vault. With the Secrets Management module, we are now able to access a CyberArk vault and use credentials stored there for various PowerShell operations. Check out this modules' GitHub page as well.

Prerequisites

Do not forget to check on any prerequisites any of these sub-modules

• psPAS Powershell module
• CredentialRetriever Powershell module
• SecretManagement Powershell module 

We can install the additional modules:

Install-Module psPAS

Install-Module CredentialRetriever

CyberArk PS module installation

Install-Module SecretManagement.CyberArk

Import-Module SecretManagement.CyberArk

Commands available in the module:

Get-Command | Where Source -eq SecretManagement.CyberArk

Which reveals these cmdlets:

Get-Secret

Get-SecretInfo

Remove-Secret

Set-Secret

Test-SecretVault

Note: Depending on your setup, you may have to run -AllowClobber for the module.

When reading through the documentation for the CyberArk GitHub, you will notice that there are three different connection setups for your CyberArk vault: Credential Provider, Central Credential Provider, and REST. Use the one that corresponds to your individual CyberArk configuration. Once configured, we can use the Secret Management cmdlet to manage our Secrets that will be stored in the vault.

Recommendations – What to do next

Securing our secrets should be something that is always on our minds in the Technology field. We should be even more aware after the Salesforce hack / clear text credential incident. Microsoft's Secrets module for PowerShell opens up a more secure way to run scripts, either as one-offs or automations. Any script that uses credentials should be treated as a secret that no one else should have access to and if you aren't managing y our secrets, you should be. The first thing to do is to build out a testing lab and at the very least use Microsoft built-in Secret Stores. Once tested, pick a credential provider that perhaps you already use for other application credentials (i.e. CyberArk) and use it for your PowerShell Secrets manager. Then when this test or proof of concept is completed and vetted, move it to production and secure your PowerShell scripts.

Related links

• Security e-book 
• GitHub page of the module
• ScriptRunner: Try out our Software for free and download the Trial Version