Stop hardcoding secrets! Now what?!
Yeah, we all know this right “STOP DOING THIS”, “STOP DOING THAT!” Yeah… that’s nice, but now what?! When you are already in the PowerShell field for some time and have created some scripts you might have been running into this topic; ‘How to deal with secrets’. There are of course solutions like KeyVault, SecureString and secret providers with API’s which help you to store the secrets you have in a secure environment. Things like this might look familiar; $password = "P@ssw0rd123!" $apiKey = "sk-1234567890abcdef" $connectionString = "Server=myserver;Database=mydb;User=admin;Password=SuperSecret123;" But what if I told you there’s a better way? A way that’s: Secure by default Cross-platform (Windows, Linux, macOS) Works with multiple backends (local, Azure Key Vault, HashiCorp Vault) Standardized across your entire team Built right into PowerShell 7+ (with some extra module support) That way forward is called ‘PowerShell SecretManagement”! What is SecretManagement? Think of PowerShell SecretManagement as the universal remote control for your secrets. With this remote control you can handle credentials for different systems while you just get one unified interface. It doesn’t matter if that secret is stored: In your local machine In an Azure KeyVault In HashiCorp Vault In KeePass, LastPass etc. The mindset remains the same ‘One remote control, to control them all’. The architecture behind it looks a bit like below; Explaination: SecretManagement “The interface where you code against” SecretStore “The default storage where your secrets live” Getting Started Let’s get started! Start PowerShell 7+ and run the code below Install-Module Microsoft.PowerShell.SecretManagement -Repository PSGallery -Force Install-Module Microsoft.PowerShell.SecretStore -Repository PSGallery -Force Now we have the required modules installed form the PowerShell Gallery it’s time to create our first vault. Register-SecretVault -name "LocalTestVault" It will ask you for the module. Enter the name “Microsoft.PowerShell.SecretStore”. (If you want you can also specify this value directly in the CMDLet by specifying the -ModuleName parameter. You should end up with something like below: First secrets Now we have the vault set-up it’s time to add some content to it. Follow the steps below to create the first secret in the vault Run the command below to create the first secret Set-Secret -Name "TestSecret" -Secret "SuperDuperSecureSecretString" If you haven’t specified the password it will now ask for one! You should end up with something like below; Cool right? On my personal blog I have the full post where I also show how to change, delete, and store complex objects. You can find it here: https://bartpasmans.tech/powershell-stop-hardcoding-secrets-now-what/ Happy scripting!
resolve-dnsname returns odd data
hi, appreciate your time. I am working with resolve-dnsname and I am seeing some odd results. for example: resolve-dnsname -server 10.0.20.5 -name "60.16.40.194.in-addr.arpa" -NoHostsFile -type ptr Name Type TTL Section NameHost ---- ---- --- ------- -------- 60.16.40.194.in-addr.arpa. PTR 1200 Question LNB050825-LT3 so here is what's weird about this.... when I look at my dns server with dns manager and look at the reverse zone, I do not have a record for this IP address: Also, when I look at the resolve-dnsname data, I see there is something called "Section", and it is set to "Question". Also notice that the "NameHost" is short and not a FQDN. The "Section" is interesting because on requests the return the right data, Section is set to "Answer". Equally weird is that if I pick a different IP that I also know does not exist, I get this: PS C:\Trash> resolve-dnsname -server 10.0.20.5 -name "60.1.40.194.in-addr.arpa" -NoHostsFile -type ptr Resolve-DnsName: 60.1.40.194.in-addr.arpa : DNS name does not exist. this is what I would expect if the record does not exist....so what is happening in the first example? Thanks in advance for anyone's time on this.Using Desired State Configuration (DSC) v3 on Windows Server 2025
Microsoft Desired State Configuration v3 has some substantive changes compared to previous versions of the technology. Unlike PowerShell Desired State Configuration (PSDSC) v1.1 and v2, DSC v3 operates as a standalone command rather than a service, eliminating the need for a local configuration manager. This architectural change makes DSC v3 easier to use and scale, allowing any tool that can execute commands on Windows Server, such as Scheduled Tasks, to apply DSC configurations. You can install DSC using WinGet. Windows Server 2025 includes built-in support for WinGet, making the installation process more straightforward than on previous server versions. However, it's important to note that winget is only available for Windows Server 2025 with Desktop Experience and can’t be used with Server Core deployments. DSC v3 requires PowerShell 7.2 or later. As Windows Server 2025 comes with Windows PowerShell 5.1, you'll need to install PowerShell 7.x separately, which you can do manually or using WinGet from an elevated PowerShell session. winget install microsoft.powershell The PSDesiredStateConfiguration module specifies a minimum PowerShell version of 7.2 in its module manifest. WinGet provides the most straightforward installation experience with automatic updates: Open PowerShell with administrative privileges Install the stable version using: winget install Microsoft.DSC Alternatively, download the latest release from the PowerShell/DSC repository and add the folder containing the expanded archive contents to your PATH environment variable. Basic DSC v3 Commands To view all available commands in DSC v3, use: dsc --help The output will display available commands including: completer - Generate a shell completion script config - Apply a configuration document resource - Invoke a specific DSC resource schema - Get the JSON schema for a DSC type help - Display help information for commands To see the resources available for use in configurations: dsc resource list This command displays all DSC resources installed on your system that can be used in configuration documents. Creating DSC v3 Configurations DSC v3 configurations can be written in YAML format, which is more concise and readable than the MOF format used in previous versions. A DSC v3 configuration document must include: A reference to the DSC resource schema At least one resource definition with properties Creating a Basic Configuration Here's an example of a basic configuration in YAML format: $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json resources: - name: Force icon view in Control Panel type: Microsoft.Windows/Registry properties: keyPath: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\ valueName: ForceClassicControlPanel valueData: DWord: 1 This configuration sets a registry value to force the Control Panel to display using the classic icon view. For compatibility with classic PowerShell resources, you can use the WindowsPowerShell resource type: $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json metadata: name: IIS-Configuration resources: - name: Use Windows PowerShell resources type: Microsoft.Windows/WindowsPowerShell properties: resources: - name: Web server install type: PSDesiredStateConfiguration/WindowsFeature properties: Name: Web-Server Ensure: Present This configuration uses the classic WindowsFeature resource from the PSDesiredStateConfiguration module to install IIS. Once you've created a configuration document, you can test and apply it using DSC v3 commands. To test a configuration to see what changes would be made (rather than shouting Cowabunga on production systems) run the following command: dsc config get -f .\iis-config.yaml This command assesses the current state without making changes, showing what would happen if you applied the configuration. To apply a configuration run a version of the command (with your yaml file specified): dsc config set -f .\iis-config.yaml This command applies the configuration defined in the YAML file to your system. You can find out more about DSC v3 at the following locations: https://devblogs.microsoft.com/powershell/get-started-with-dsc-v3/ https://github.com/PowerShell/PSDesiredStateConfiguration https://learn.microsoft.com/powershell/dsc/overview?view=dsc-3.0&preserveView=true https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5
A little help please with Get-AzADObject
I am trying to write a PowerShell script that will list the users who hold specified Azure roles into a .csv file for security reviews. I'm new to PowerShell and I'm struggling with this for far too long on my own. Here's what I've got: I keep getting the error: Get-AzADObject: The term 'Get-AzADObject' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. I've already used: Get-Module AzureAD Install-Module AzureAD Import-Module AzureAD With no errors on any of those. What am I missing, please?
powershell on mac
Hello Everyone, I’m new to using PowerShell on a Mac. I was given a PS1 script that needs to be run on a Mac device to check the files and folders of logged-in users. I managed to achieve this to some extent, but now I’m stuck on granting full disk access to the PWSH app via a Jamf Pro privacy payload. Since the PWSH app is not a signed package, I was unable to identify the “code requirements” to add a payload in Jamf Pro. Could you please share your best practices for deploying PowerShell and granting it full disk access via Jamf Pro?
Cannot dot-source this command because it was defined in a different language mode.
Microsoft.PowerShell_profile.ps1: Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator. I am getting this error when I open my PowerShell anywhere... I have few scripts present in my PS Profile, but this is failing with error, and I can't import, its blocking me to even set a property. $Host.Name = 'Test' InvalidOperation: Cannot set property. Property setting is supported only on core types in this language mode. Can someone please help me to get rid of this issue. Thanks!
PowerShell support on Linux
I am trying to invoke Powershell 7.4 on Linux RHEL8 through a java program and submitting commands and reading output using streams. As soon as the powershell starts , the inputstream is reading some unknown characters from the powershell output for e.g. '[?1h' and '[?1l'. I need a way such that I don't read these characters. I tried setting the encoding in the input stream to UTF-8, but that didn't solve the problem. Would really appreciate if someone could provide some inputs on this.Regarding the different output formats of Powershell Versions 5 and 7.
I use Exchange Online commands through Powershell. I have noticed that Powershell versions 5 and 7 work differently. And I would like to achieve an output format like Powershell version 5, but without using the "｜Format-table" notation. Is it possible to rewrite the default values? Thank you. Powershell version information in use: PowerShell 5: 5.1.22000.653 and PowerShell 7: 7.2.5
