11 min read
Graph PowerShell SDK – Part 1 of our Graph series
Users will encounter one or two hurdles when they start using Graph. Damian Scoles wrote three articles provides help...
ScriptRunner Blog
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!
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.
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.
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:
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.
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-Module Microsoft.PowerShell.SecretManagement
Install-Module Microsoft.PowerShell.SecretStore
Import-Module Microsoft.PowerShell.SecretManagement
Import-Module Microsoft.PowerShell.SecretStore
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
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
Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore
Set-Secret -Name M365GA01 -Secret "!@dF45#281*sdf" -Vault SecretStore
Remove-Secret -Name TestSecret -Vault SecretStore
Set-Secret -Name M365GA01- Vault SecretStore
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.
Get-SecretStoreConfiguration
As we can see, the default timeout is 900 seconds or 15 minutes
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.
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.
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.
$Credential = Get-Credential -UserName 'SecureStore'
$PasswordPath = 'C:\data\password.xml'
$Credential.Password | Export-Clixml -Path $PasswordPath
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault
$Password = Import-CliXml -Path $PasswordPath
Unlock-SecretVault -Name SecretStore -Password $Password
Unlock-SecretVault -Name SecretStore -Password $Password
Set-Secret -Name TestSecret -Secret "TestSecretPassword" -Vault SecretStore
$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.
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.
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
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 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.
Do not forget to check on any prerequisites any of these sub-modules
We can install the additional modules:
Install-Module psPAS
Install-Module CredentialRetriever
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.
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.
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.
We also sometimes cover the topic in a webinar. For our last webinar, you can request a recording!
Oct 8, 2024 by Damian Scoles
Users will encounter one or two hurdles when they start using Graph. Damian Scoles wrote three articles provides help...
Oct 2, 2024 by Heiko Brenn
Managing Active Directory (AD) is a crucial yet time-consuming task for IT administrators. The constant need to manage...
Sep 30, 2024 by Frank Kresse
We have just released our latest ScriptRunner update, version 7.1, packed with powerful new features aimed at making IT...
Damian Scoles is a ten-time Microsoft MVP specializing in Exchange, Office 365 and PowerShell who has 25 years of IT industry experience. He is based in the Chicago area and started out managing Exchange 5.5 and Windows NT. Over the years he has worked with Office 365 since BPOS and his experience has grown to include Azure AD, Security and Compliance Admin Centers, and Exchange Online. His community outreach includes contributing to TechNet forums, creating PowerShell scripts that can be found on his blogs, writing in-depth PowerShell / Office365 / Exchange blog articles, tweeting, and creating PowerShell videos on YouTube. He has written five PowerShell books and is also actively working on the book "Microsoft 365 Security for IT Pros".