Skip to the main content.

ScriptRunner Blog

PowerShell Secrets – Bulletproof password management

Table of contents

Post Featured Image

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.

01_secrets management

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:

SecretManagement module

SecretStore module

Get-Secret Get-SecretStoreConfiguration
Get-SecretInfo Reset-SecretStore
Get-SecretVault Set-SecretStoreConfiguration
Register-SecretVault Set-SecretStorePassword
Remove-Secret Unlock-SecretStore
Set-Secret  
Set-SecretInfo  
Set-SecretVaultDefault  
Test-SecretVault  
Unlock-SecretVault  
Unregister-SecretVault  

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

02_timeout secret store configuration

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

 

Extending or shrinking the timeout


Set-SecretStoreConfiguration -PasswordTimeout 1800

03_confirm timeout secret store configuration

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.

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

04_list of sub-modules for secrets management

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

 

05_credential sets

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.

06_remove-secret

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.

 

 

Good2know

Your comprehensive PowerShell security e-book

Using PowerShell securely is key to succesfully automating IT administration tasks. Our 150-page PowerShell security ebook covers all built-in features to keep your PowerShell environment safe and reliable.

  • Control execution of scripts using execution policy
  • Delegate administrative tasks with JEA
  • Code signing and constrained language mode
  • Audit and analyze PowerShell activities, encrypt logs
  • Secure PowerShell remoting with SSH and TLS
  • Improve code quality following best practices

Ebook-graphic-new

Get your ebook here!

 

We also sometimes cover the topic in a webinar. For our last webinar, you can request a recording!

PowerShell security best practices 

Topics covered in the webinar:

  • How to use the PowerShell SecretManagement module
  • Working with execution policies
  • Secure credential management
  • Password server integration
  • Delegation of single, parameterizable PowerShell scripts without administrative rights of the user
  • Secure browser-based execution of PowerShell scripts


Request your recording here!

  

 

Related links

Related posts

14 min read

Privacy Management with PowerShell – Let's look at the core features of Priva!

All you need to know about Privacy Management, privacy management policies, rules, and subject rights requests.  

Why...

4 min read

Let's celebrate System Administrator Appreciation Day!

Every last Friday of July, we get to celebrate System Administrator Appreciation Day, a special day dedicated to...

8 min read

PowerShell 7: What are the pros and cons of switching from Windows PowerShell 5.1?

Windows PowerShell 5.1 is usually preinstalled and the default – is it worth switching to PowerShell 7, or will it lead...

About the author: