ConvertTo-SecureString Key not valid for use in specified state
I'm getting an error when running a script as a particular user, but not as my own user account. This is on Windows 2012R2. Powershell module was installed and has been in use for some time, but using another account prevents it from running. Because I have been able to run it, I feel like I can rule out any missing files or faulty commands within the script. The rest of the script is dependent on this. I also have run the convertto-securestring options using the service account that will be running the commands through the automation, but it still is not working.
This is the secure password script I ran to convert the password
$password = "password"
$secureStringPwd = $password | ConvertTo-SecureString -AsPlainText -Force
$secureStringText = $secureStringPwd | ConvertFrom-SecureString
Set-Content "E:\temp\ExportedPassword.txt" $secureStringText`
This is the error message after trying to run as user B
line 4 $pwdTxt = Get-Content "E:\temp\ExportedPassword.txt"
line 5 $securePwd = $pwdTxt | ConvertTo-SecureString
ConvertTo-SecureString : Key not valid for use in specified state.
At E:\temp\get_user_cliffsv4.ps1:5 char:24
+ $securePwd = $pwdTxt | ConvertTo-SecureString
+ ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [ConvertTo-SecureString],
CryptographicException
+ FullyQualifiedErrorId :
ImportSecureString_InvalidArgument_CryptographicError,Microsoft.PowerShell.
Commands.ConvertToSecureStringCommand
I have run this script numerous times through automation software, but when testing I had to run the command as my personal account because of this error and to get around this so I could complete testing, I invoked that option. My question is, is the account I'm using missing any particular rights? Do I have to install the Powershell extensions under that account or can I set/change something in PS or on the server that will allow the service account to run this script? Thanks in advance!
Answer
The issue was not the service account's ability to run the command, it was that the System account was running the command, so the secure password it was passing was not usable. I found this link that provided a script that scheduled the script to run using the system account, thereby creating the file by system which will correctly used the password file and passed the credentials correctly. Thank you to Keith Francis and the site for hosting the code and always, I'm very thankful for these communities that provide an outlet for support.