PowerShell / SecretStore

MIT License
158 stars 24 forks source link

Unlock-SecretStore returns "Padding is invalid and cannot be removed" #53

Closed OneUser1 closed 3 years ago

OneUser1 commented 3 years ago

I received this error on more than one device when trying to access a SecretStore in a script (non-interactively) or by using Unlock-SecretStore interactively. I am not aware where I did a mistake. An internet search led me to this post: https://www.red-gate.com/simple-talk/blogs/oh-no-my-paddings-invalid/. Could this be a bug? I receive the error not always and on a Win10 Ent or W2k8 R2 Std.

Can anybody help? image

OneUser1 commented 3 years ago

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 commented 3 years ago

"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 commented 3 years ago

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...).

OneUser1 commented 3 years ago

@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!

PaulHigin commented 3 years ago

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 commented 3 years ago

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:

So, today I did the following:

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

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 commented 3 years ago

Testing using a SecretStore without a password:

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 commented 3 years ago

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: https://github.com/PowerShell/SecretManagement/issues/118

OneUser1 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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.

https://github.com/PowerShell/SecretManagement/issues/118

OneUser1 commented 3 years ago

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.

PaulHigin commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.