Start-Process and -Credential Issue

We have a requirement to launch PowerShell scripts via a product called Jenkins and have run into an issue. I have been assisting my colleague in resolving this issue and note the issue also occurs when running the script/s using an alternative scheduler e.g. Windows Task Scheduler. Therefore the issue is not directly related to Jenkins is appears to be a generic issue as explained in detail below.

I have boiled the issue down, and found it occurred when you combine the following
1: -credential parameter i.e. type System.Management.Automation.PSCredential
2: non manual execution of the script/s (e.g. via Windows Task Scheduler etc. as noted above)

I have explained the issue below using a couple of basic scripts (not production scripts) which demonstrate the exact nature of the issue.

If you have two script as follows (the below just demonstrates the issue)

#Script1
$cred_password = ConvertTo-SecureString “Pa$$w0rd” -AsPlainText -Force
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist “Domain\UserB”, $cred_password

try {

start-process C:\Windows\SYSTEM32\WindowsPowerShell\v1.0\powershell.exe -ArgumentList ‘-noprofile -executionpolicy bypass -file C:\temp\script2.ps1’ -Credential $cred -ErrorAction Stop

}catch{$Error[0] | Out-File “C:\temp\error.txt” -Force}
Then you have another script

#script2
Get-Service | Out-File C:\temp\Services3.txt -Force -Confirm:$false

Now if you open a PowerShell command prompt as UserA (e.g. not the one in the above $Cred) and run C:\temp\script1.ps1 it works no worries e/g/ script1 runs and the start-process with the -credential executes script2 as UserB (the point here being you are running manually)

However as soon as you add script1 to a scheduler let’s use Windows Task Scheduler and run Script1 as a scheduled task under user ID UserA (weather they are logged in or not) the scheduled tasks runs Script1 but does not appear to run Script2 and can see no errors returned.

If you then remove the -credential from the Start-Process cmdlet and let the scheduler run it again it works. (However in reality UserB would have higher rights which is the point of using the –credential parameter)

Therefore appears to be a combination of using a credential object when running from a scheduler (as running manually always works).

I need assistance in resolving this issue or finding a practical workaround (cause and resolution would be better)

The same issue appears swapping out start-process with invoke-command (different commands) and again using the -credential parameter e.g. runs manually but not via unattended method

Thanks All
AZUser

You’ve run into the situation where -credential is designed NOT to work. Essentially, you’re storing a password in more or less plain text; the way a secure string works is actually the root cause of the problem, and it has a bit to do with the way secure strings are created and then de-constructed. Doing that across user accounts can be problematic.

The intended way to do this is not not use a -credential parameter at all. Instead, Task Scheulder or whatever would be configured to run command under an alternate credential. Task Scheulder obviously does this; I don’t know if your Jenkins tool does or not, but that’s what would need to happen.

Thanks very much for the reply Don,

Is it because secure string uses something about your login as the encryption key e.g. your SID or GUID as an input key to an algorithm to some up with the secure string?

That would explain it :slight_smile:

if so I may be able to get around this by using the -Key parameter when creating the secure string, e.g. use a random byte array as the the key for AES, then encrypt this KEY using x509 cert private key then store on disk. Read back in when creating the secure credential.

what do you think? I will give this a go and let you know how I get on,

thanks again for the info, this really helps :slight_smile:

AZUser

Thanks very much for the reply Don,

Is it because secure string uses something about your login as the encryption key e.g. your SID or GUID as an input key to an algorithm to some up with the secure string?

That would explain it :slight_smile:

if so I may be able to get around this by using the -Key parameter when creating the secure string, e.g. use a random byte array as the the key for AES, then encrypt this KEY using x509 cert private key then store on disk. Read back in when creating the secure credential.

what do you think? I will give this a go and let you know how I get on,

thanks again for the info, this really helps :slight_smile:

AZUser