Universal module not imported into Endpoints

[adamdriscoll]

Steps to Reproduce

https://forums.ironmansoftware.com/t/secret-scope-in-v3-0-1/7245

Expected behavior

Universal should be imported to all environments

Actual behavior

Universal is not imported and secrets don't work.

Environment data

v3.0.1

Visuals

No response

[adamdriscoll]

This issue has been mentioned on Ironman Software Forums. There might be relevant details there:

https://forums.ironmansoftware.com/t/secret-scope-in-v3-0-1/7245/2

[rjvrijn]

Hmmm, it seems like I still have this issue in 3.0.2 under scripts. Also when I add a secret variable from within the GUI it does not store the variable. Tried both builtinsecretvault and psusecretstore. Importing universal in settings or in the script does not seems to help. ps. I'll reply for this on the forum next time, but it seems that I never signed up for it until now. :confused: :flushed:

[adamdriscoll]

@rjvrijn - We did fix the issue with storing the secret variables but the module should be imported: https://docs.powershelluniversal.com/changelog#platform

can you try this again on 3.0.3?

[rjvrijn]

Hi Adam,

I just tried it with version 3.0.3. I am still not able to store secret variables in the BuiltInLocalVault. Also tried the PSUSecretStore.

I have an automated installation method to install a plain new version of the binaries and the universal module when I want. It is based on removing the c:\programdata\PowershellUniversal and c:\programdata\UniversalAutomation directories (legacy from older versions and ZIP file based installation(extraction)).

I create the secrets with the following code, but when I create the variables from within the GUI the secret is not stored also. The last known version where it worked for me was 2.9.2.

The script is running under the integrated environment, where I did load the universal module as far as I can tell. I'd import the universal module in the script also. Besides that when I create the variable in the GUI, the 'button' "set secret value" is not cleared and the (scheduled) script keeps displaying the message: 'You cannot call a method on a null-valued expression.' (or display nothing when I try to write the content to the host ;)).

The only difference left, is that I run powershell universal under NSSM, under a privileged account, (call to start-powershellUniversal.ps1 which in turn run C:\ProgramData\PowerShellUniversal\Server\universal.server.exe --service, but starting universal.server.exe directly gives the same result.

$address = "http://localhost:5000"
Invoke-RestMethod -UseBasicParsing -Uri "http://localhost:5000/api/v1/signin"
-Method Post -Body (@{ username = 'admin'; password = 'admin' } |
ConvertTo-Json) -SessionVariable 'PUWS' -ContentType 'application/json'

$body= [pscustomobject]@{
"name" = "test_pscredential"
"value" = 'secret'
"username" = 'testsecret'
"password" = 'secret'
"secret" = "true"
"vault" = "BuiltInLocalVault"  # "PSUSecretStore"
"type" = "PSCredential"
}
Invoke-RestMethod -UseBasicParsing -Uri "$Address/api/v1/variable"
-WebSession $PUWS -Method post -Body ($body|convertto-json) -ContentType
application/json-patch+json | out-null

NB. Process and actions are run under PSCore 7.2.4. ;)

Hope this helps to pinpoint it (and that I not miss a simple step in this troubleshooting)

Sincerely,

Rene van Rijn

On Wed, Jun 22, 2022 at 2:23 PM Adam Driscoll @.***> wrote:

@rjvrijn https://github.com/rjvrijn - We did fix the issue with storing the secret variables but the module should be imported: https://docs.powershelluniversal.com/changelog#platform

can you try this again on 3.0.3?

— Reply to this email directly, view it on GitHub https://github.com/ironmansoftware/issues/issues/1239#issuecomment-1163031634, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM6AJSXG2NBP6JBV2GVBEWDVQMAVFANCNFSM5Y3FCXUQ . You are receiving this because you were mentioned.Message ID: @.***>

[adamdriscoll]

The Set Secret Value should always be present in this version so you can update secret values. If the secret doesn't actually exist, a red indicator will be present on the left of the secret saying the value doesn't exist.

I may have to try with NSSM because both of these secret vaults are user specific so there could be something happening there. We have integration tests in place that create secrets via the API so what you are doing is pretty standard so there is something else we are missing.

[rjvrijn]

My whole Universal endpoint environment (incl. tags, variables, scripts, schedules and securing the GUI to authenticate the login with the AD credentials), is created with api calls. I'll start a new empty basic installation and will try to create a pscredential in the GUI and by API call then. I'll let you know the result.

[rjvrijn]

I did a basic installation of 3.0.3 by extracting the Zip file and imported the universal module of the same version in PsCore. After that I started Powershell Universal manualy from within the same PSCore session, logged as Admin/Admin and created a PSCredential from within the GUI. It still looks like it didn't save the variable in the vault. It keeps showing "+ Set Secret Value" even after setting the secret using that 'button'. Its not stored by API either.

After that I added the universal module in the builtin environment and repeated the steps with the same results.

I don't know what I'm missing, I only know that the last universal version were it worked for me was 2.9.2 (3.0.0 and 3.0.1 not tested).

The installationpath is c:\programdata\PowershellUniversal and the database is stored at its default location (c:\programdata\UniversalAutomation).

I'm sure I'm missing something (I don't read the releasenotes on every upgrade; yeh I know, I'm sorry. ;) ).

ps. Standard logging does not trigger a message, I'll do some more testing in the weekend with debug logging on.

I used this testscript under Automation->Scripts:

Write-Output "The length of `$Testpscredential is: $($Testpscredential.length)"

Write-Output "The username in Testpscredential is: $($Testpscredential.username)"

Write-Output "The length of TestStringvar is: $($TestStringvar.length)"
Write-Output "the content of TestStringvar is: $TestStringvar"

Write-Output "The length of `$Testpscredential2 is: $($Testpscredential2.length)"

Write-Output "The username in Testpscredential2 is: $($Testpscredential2.username)"

Write-Output "The length of `$Test3 is: $($Test3.length)"

Write-Output "The username in Test3 is: $($Test3.username)"

Which generated this result: Jun 24, 2022 2:18 PM The length of $Testpscredential is: 0 Jun 24, 2022 2:18 PM The username in Testpscredential is:
Jun 24, 2022 2:18 PM The length of TestStringvar is: 20 Jun 24, 2022 2:18 PM the content of TestStringvar is: ValueOfTestStringvar Jun 24, 2022 2:18 PM The length of $Testpscredential2 is: 0 Jun 24, 2022 2:18 PM The username in Testpscredential2 is:
Jun 24, 2022 2:18 PM The length of $Test3 is: 0 Jun 24, 2022 2:18 PM The username in Test3 is:

[adamdriscoll]

In v3, we introduced the $Secret scope so you need to do:

Write-Output "The username in Testpscredential is: $($Secret:Testpscredential.username)"

The reason for this change was that when accessing this way, we are doing it on demand rather than loading it into memory on startup (even if it wasn't used).

[rjvrijn]

Hi Adam, thank you. Indeed I did read on the forum that the scope $secret: is needed to access the pscredential, but in earlier tests it did not solve my issue, and I forgot to use the scope in this test. That said, I now have a result to work on. The var I created from within the GUI does return a value, but the vars I created by the APi doesn't. However that has to be an issue on my side that is not too hard to find. I'll update you on this after the weekend.

Thank you for your quick (as always) response.

Sincerely,

Rene van Rijn

[rjvrijn]

Update:

All is working well now. As you said, I need to use the $secret scope. The reason why it wasn't working in my earlier tests is one that I'm a little ashamed to say: the variable name is now case sensitive.

So in the initial tests, after I added the $secret scope, my vars still returned $null because the scripts use lowercase were uppercase was needed. After that I start to try a lot of other things but never turned back to the $secret scope. :flushed:

Although case sensitive vars do help make the code more neater and the behavior is more similar to linux, I overlooked this in the first place because I'm not aware of this behavior in Powershell core/Windows.

Sincerely,

Rene van Rijn