I’m trying to use the secret module to store credentials in the built in local vault (using the Set-Secret cmdlet in the authentication.ps1 file) and pull/use the user’s credentials while on the dashboard (using the Get-Secret cmdlet).
The secret cmdlets do not appear to be working. After the dashboard loads, the red error banner shows on the dashboard as "The 'Get-Secret' command was found in the module 'microsoft.powershell.secretmanagement', but the module could not be loaded. For more information, run 'Import-Module 'microsoft.powershell.secretmanagement'.
This has been happening on 2.8.1, 2.8.2 and now 3.0.0.
@adam , Import-Module microsoft.powershell.secretmanagement returns null, as in it successfully imports the secretmanagement module. I can open a powershell window and set/store secrets in a newly created vault. My issue is during dashboard run time (the same commands I run manually are not working when the dashboard loads )
My previous comment was referring to opening a new PowerShell window and importing the module (successfully). I do have “Import-Module microsoft.powershell.secretmanagement” in my dashboard file and the error message that pops up when the dashboard loads is the following:
Errors occurred while loading the format data file: C:\Program Files\WindowsPowerShell\Modules\microsoft.powershell.secretmangement\1.1.2\Microsoft.PowerShell.SecretManagement.format.ps1xml, , C:\Program Files\WindowsPowerShell\Modules\microsoft.powershell.secretmanagement\1.1.2\Microsoft.PowerShell.SecretManagement.format.ps1xml: The file was skipped because of the following validation exception: AuthoriztionManager check failed.
@adam I noticed the Microsoft.PowerShell.SecretManagement module is not listed in the admin page under dashboards - Components. Also if I place the module there, it shows up in the admin page, but still gives the same error when loading the dashboard on the user’s side.
Did you install this with Install-Module? I’ve seen this error happen when the module was blocked and have had to use Unblock-File to get it to load. Install-Module does that automatically so that might not be it.
Thanks for the reminder on the file blocker @adam ! I need to get in the habit of double checking that. I unblocked the file, then imported the module in the dashboard file, but I’m still not seeing the module during dashboard runtime. Interesting enough, It is successfully importing “Microsoft.PowerShell.SecretStore.psd1” but not “Microsoft.PowerShell.SecretManagement.psd1” and therefore can’t pull in the secret credentials.
Man…the only thing I can think of is that something is conflicting with the secret management module in the dashboard (probably another module) since I don’t see this on a clean install.
There was another copy of the “Microsoft.Powershell.SecretStore” module located in C:\Program Files\Windows PowerShell\Modules. Initially I was unable to delete it but once I stopped the PowerShell service I was able to remove that module folder. PSU must have been using that location.
Now I’m seeing the output you’re getting above, but the secret modules still don’t seem to be available. I even opened a PowerShell window on the server hosting PSU, Imported the module successfully but when I tried to set a secret, it throws an error because it’s still looking in C:\Program Files\Windows PowerShell\Modules for the Microsoft.PowerShell.SecretStore module.
@adam PSU looks in C:\ProgramData\PowerShellUniversal\Dashboard\Components to load modules in realtime (when the dashboard is loaded), correct? And is there something else I can change to point them to look in C:\ProgramData…?
@adam I’m logged in with my domain user credentials (we’ll call it drewk). Are you saying that the contents you listed above need to be modified underneath the service account’s profile and not under my profile as in C:\Users\ServiceAccountName\AppData\Local\Microsoft\PowerShell\secretmanagement\secretvaultregistry ? There currently is nothing in this folder under the SA’s profile but there is under my drewk profile.
You need to update this file for whatever account is running PowerShell Universal since these settings are per user.
The other thing you can do is use Register-SecretVault to set the proper paths for the account that is running PSU. You’d have to run that in the context of the user running the PSU service.
So it looks like when users log on, the PSUVariables are being created, but the authentication.ps1 code is no longer capturing their credentials username and password. I’m still using the API format here Importing Secret Variables (with script) - #4 by adam that was working a while back. Currently when I check what is stored in a recently created PSUVariable, the username and password field is null.
I was previously successfully using $WindowsCredentials = Get-PSUVariable -Name $User to store the credentials when the dashboard loads and then using $WindowsCredentials to run scripts with the users credentials but that no longer works (I don’t recall when it was last working but that was several versions/upgrades ago). I recently completed the steps below and the credentials started working again:
Changed how I import the credentials from the BuiltInLocalVault:
OLD - $WindowsCredentials = Get-PSUVariable -Name $User
CURRENT - $WindowsCredentials = Get-Secret -Name $User
Added the following to both appsettings.ps1 and my dashboard.ps1 files:
It is required to run the $WindowsCredentials = Get-Secret -Name $User inside of the New-UDPage -Content curly braces. When placing this outside of the UDPage content (at the top of the dashboard file) it does not gather/return the credentials and therefore cannot be used inside of the UDPage.
@adam can you confirm that the two modules below used in the solution above are the modules I need for secretmanagement and that I’m pointing to the correct location of those modules? Feel free to steer me in the right direction when I may be veering off track.
