After manually running Add-Secret, Get-Secret run as a script failed to retrieve the secret

[swinster]

I suspect this will be a context issue, but would like to double check.

Steps to reproduce

Manually enter Creds:

$Creds = Get-Credentials
Add-Secret -Name MyUserCred -Secret $Creds

Then, a script that is run as part of another process/application uses:

$Creds = Get-Secret -Name $_.CredName

(where '$_.CredName returns the credential to use "MyUserCred"

Expected behavior

Credentials are found.

All is actually fine when testing with VScode manually

Actual behavior

Exception when script ran:

Get-Secret: The secret MyUserCred was not found.

Environment data

Module version:

Name                           Value
----                           -----
PSVersion                      7.0.0-rc.2
PSEdition                      Core
GitCommitId                    7.0.0-rc.2
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[swinster]

OK, so I have had some feedback from the application devs where this scripts is invoked. As suspected, the application service runs using the local machine account, so not the user context. I guess it would be great to be able to populate and reference the local machine service credentials store.

[PaulHigin]

Yes, this module is reliant on Windows Credential Manager to store secrets in the built-in local vault, as well as storing additional parameters for vault extensions. A user logon context is required by CredMan to store/retrieve secrets, and for security reasons a service account is not supported. So script that uses this module to retrieve secrets must run under the same user account used to store the secret.

[swinster]

I take it that there is no way to use a Windows Credential Manager or some other local vault to store machine context creds? There will be a lot of applications and scripts that will not run in the user context, but you will still want creds stored safely.

[PaulHigin]

Not that I know of. I believe this is a security issue and storing secrets under a service account leaves them vulnerable (similar questions such as this have been asked about using CredMan directly). AFAIK the only secure way to store local secrets is via logon accounts backed by credentials.

[PaulHigin]

Closing this issue, since behavior is by design in Windows Credential Manager.

[JustinGrote]

@swinster you shouldn't be running scripts as SYSTEM anyways for security reasons, just set up a named service account and set the service to use that service account (it can be local to the machine) and give it least privilege access to what it needs.

[swinster]

I personally am not @JustinGrote , however the app I'm using (Certify the Web) currently does as it runs as a service, and the scripts are evoked from there.