Unlock-SecretStore returns "Padding is invalid and cannot be removed" about secretstore

[OneUser1]

@PaulHigin After deleting the user profile from the server and starting from scratch it worked just fine. I am thankful for that. In between the only possible thing is that the username was changed in the AD. But a second script using the same user and therefore the same secret vault did not show these errors..

Thanks for your help! It is a cool project!

[OneUser1]

Thanks again for the reference issue. What we do with that scheduled task is what Justin Grote described as supported szenario No. 2: Usage in scripts run by an interactive user with pre-configured vault and/or secret names.
The scheduled task runs under this interactive user (what I called a service user above was not technically correct but this is what more people I know call it) and launches the script which access the SecretStore.

After fixing this proxy problem the scripts runs just fine in every possible way (scheduled task, PS run as the user, PS in an RDP session in the user context).

Further I was not able to reproduce the padding error. I do not think that the proxy and padding errors share one and the same reason but because I am not able to reproduce the behaviour I will close this issue.

Thanks for all your effort! I appreciate that.

[OneUser1]

I now changed how the SecretStore password is read from file and this issue persists (now it uses Import-Clixml).
Further I saw on the W2k8 R2 machine that when running the script from console it works. When running as a scheduled task it does not unlock the SecretVault with the error above. I was using the exact same user running the script and the exact same PowerShell command. I will test with the Win10 machine tomorrow again.

[PaulHigin]

"When running as a scheduled task..."

A scheduled task will run in a system account (if not launched from an interactive account) and this may explain the error. In any case you cannot run Read-Host in a scheduled task since that will usually run in a non-interactive account.

The -Scope AllUsers configuration is intended to address this kind of machine-wide use, but is not yet implemented (maybe for v1.1). SecretStore currently only supports use within a user account -Scope CurrentUser.

[OneUser1]

Hello @PaulHigin, thanks for your answer. My second post was easy to misunderstand. Sorry for that.

I am not using Read-Host as in the first post. In the script I read the password from a file using Import-Clixml (even before I used Get-Content to read from the file). So there was no Read-Host at any time in the script running non-interactively.

1. On the W2k8 R2 server (PS v5.1.14409.1018):
   I launch the script not using the system account but a service AD account. I can launch PS using this specific service user and then run the script (in this case it will work). When running the scheduled task under the same user with the same command line arguments it does not work. In both cases the password is read from the file using Import-Clixml.

2. On the Win10 machine (PS v5.1.19041.610):
   Scheduled task works fine as well as launching PS under the same service user as in the above test.

Hope this helps to clarify the issue. I will test setting up the PS environment on the server from scratch again. The only difference is that I install the modules manually by copying them to the server (it has no internet connection...).

[PaulHigin]

The Reset-SecretStore command was created for these kinds of scenarios, where for some reason the store files get corrupted or the password/account out of sync. But it deletes all secrets for that account and resets the secret store, so it is a last-ditch solution.

[OneUser1]

Hello @PaulHigin,

I am afraid the problem is back. I get the very same error again. FYI: We are using a single service user which runs two scripts that do two imports and need to authenticate to the appliance and to MS Graph. This user executes the scheduled tasks. When I am referring to the scheduled task or PS I always used the same command line arguments.

What I did to "resolve" it yesterday:

• Deleted user via Control Panel -> System -> Advanced System Settings -> User Profiles
• Renamed all PS module folders for SecMgmt and SecStore under C:\Program Files\WindowsPowershell\modules
• Renamed folder %localappdata%\PowerShell\secretmanagement
• Copied the two PS modules in the latest available versions to the W2k8 R2 server
• Started PS as the service user: Setup SecretStore and secret vault as you described it in Issue #46 and set password using Set-SecretStoreConfiguration which worked perfectly fine
• Added two secrets using Set-Secret with no errors (one for each script)
• Ran both scripts that should use SecretStore secrets
  • Import-MACsToNAC was fine (gets credentials from secret vault)
  • Import-DeviceToIntune returned an "unknown error" when connecting to MS Graph (looked like a network error) - I tried the following with no success:
    • Passing the needed credentials directly to the command without using the secret vault
    • Logged in with the AD service user interactively (RDP) to test whether the internet proxy works (it does)
  • Running the script from a PS while in the RDP session gave me the padding error again
    

So, today I did the following:

• Started a PS as the service user
• Tested script execution of both scripts returning the same padding error
• Run scheduled task for Import-MACsToNAC: Works fine
• Run scheduled task for Import-DeviceToIntune: Fails with the same "unknown error" from above when connecting to MS Graph
• Run scheduled task for Import-DeviceToIntune again after embedding credentials right in the script: Works fine

What I find most interesting is that yesterdays it was the other way around. It worked when running the scripts from a PS (which was launched as the other user) and it did not work when running the task. Today it

• does work for the Import-MACsToNAC using the task, but not the PS (which was launched as the service user)
• does not work for the Import-DeviceToIntune using task or PS (which was launched as the service user)

I will now just wanted to try to use a SecretStore without a password. But when running Get-SecretStoreConfiguration to see the cureent config it returned the same padding error. Seems like there is only the possibility left to use Reset-SecretStore.

[OneUser1]

Testing using a SecretStore without a password:

• Reset-SecretStore specifying a SecretStore password
• Set-SecretStoreConfiguration -Auth None
• Editing script to not use Unlock-SecretStore but just extract the secret from the secret vault using Get-Secret
  • Run from scheduled task: Does not work with error "Unable to get secret mySecret from vault myVault"
  • Run from TS (which runs as service user): Does work

I am able to manually retrieve the secret in a new PS (launched as the service user) which normally would ask me to provide a password to access the SecretStore (if a password would be required - which is not the case, but one could think that because of the error above when running the scheduled task)

It seems to be definetely an issue with this module after embedding the credentials works fine.

[PaulHigin]

Scheduled tasks may be run under different accounts, depending on how it is set up, so you may be configuring SecretStore under one account but Task Scheduler then runs script under a different service account. Service and managed accounts do not have a user profile that SecretStore/SecretManagement rely on for file location/protection. Also Windows DPAPI does not work for managed accounts (and I think service accounts), which .Net requires for SecureString type that SecretManagement relies on.

Consequently, SecretManagement and SecretStore won't work under Window service accounts or managed accounts.
This is really a Windows issue and not something that SecretManagement can easily workaround.
So for the first release this will just be a known limitation. But we will look at ways to mitigate for a subsequent release.

For more information please see: PowerShell/SecretManagement#118

[OneUser1]

I do really appreciate your effort. Thanks for that!

What I mean by service account is just an account that is used only for this purpose. It is a normal user account in AD. It definitely has access to the path where the SecretStore and the password file reside.

What I also tested:

• Storing password using Export-Clixml and getting it using Import-Clixml and .NET methods like SecureStringToBSTR() and PtrToStringAuto()- same unknown error
• Storing password using Set-Content and getting it using Get-Content (with the needed conversions from/to a SecureString in order to have it encrypted) and .NET methods like SecureStringToBSTR() and PtrToStringAuto() - same unknown error
• After these test above even plaintext passwords in the script failed with the unknown error

This points me to the system itself. Hopefully I will be able to test on another system with a later OS.

I will tell our customer that he needs to run the script manually, it just does not work using a scheduled task on this W2k8R2 server system. I am heading for holidays now so I may be able to test after the coming week. If I still think the issue is related to this module I will come back to you. So thanks for all your help so far!

[OneUser1]

Short update: We found that a proxy connection does not work when run as a scheduled task😒. This will be resolved first and then the padding error will be troubleshooted again. I will come back to you. I appreciate all help so far!

[PaulHigin]

SecretManagement and SecretStore will not work as a scheduled task since tasks run in service accounts. We will look to see if this can be addressed in a post V1 version.

PowerShell/SecretManagement#118

[PaulHigin]

If I remember right, the scheduled task will run under an interactive user account only if that user is currently logged in. If not, for instance sometime late at night, a service account is used for the task. And in this case SecretManagement will not work.

[OneUser1]

I think the interactive user account is used always when specified to be used in the task. I use the option "Run whether user is logged on or not" and I do store the user password for that (there is this prompt when you save the task).
To be sure I quickly set up a script that once in an hour copies a file to a folder from where the file will be processed by the Intune import script, which uses SecretManagement. There were 11 files and so in the last 11 hours during night the Intune import succeeded for all files. Seems like the correct interactive user account is used even while it is not logged in. AFAIK, there is no change to a service account.

[OneUser1]

Issue #62 resolved this issue. The above steps were not the solution. The problem occured again after some months. Actually the decryption error was related to a different username casing than the one used while creating the secret store. Find details there.