I'm trying to run start-process from a powershell script with given credential. Nevertheless the command fail with the following error:
Start-Process : This command cannot be executed due to the error: Access is denied
Here is the full error log:
18-Jun-2015 11:48:54 Start-Process : This command cannot be executed due to the error: Access is den
18-Jun-2015 11:48:54 ied.
18-Jun-2015 11:48:54 At C:\Windows\system32\config\systemprofile\AppData\Local\Temp\PRISMA-AMR-JOB1-
18-Jun-2015 11:48:54 87-ScriptBuildTask-8569094554411403512.ps1:38 char:18
18-Jun-2015 11:48:54 + Start-Process <<<< C:\Windows\System32\cmd.exe -arg "/C" -Credential $cr
18-Jun-2015 11:48:54 edential
18-Jun-2015 11:48:54 + CategoryInfo : InvalidOperation: (:) [Start-Process], InvalidOp
18-Jun-2015 11:48:54 erationException
18-Jun-2015 11:48:54 + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.C
18-Jun-2015 11:48:54 ommands.StartProcessCommand
Here is what the the faulty powershell call looks like:
Start-Process C:\Windows\System32\cmd.exe -arg "/C" -Credential $credential
If I open a command prompt with the appropriate credential on the machine where the script is executed, running cmd /C
does well. If it's on the powershell script on behalf of start-process it fails.
Maybee I should say that when I manually run the command prompt with targeted credential I was logged as administrator while the powershell looks to be run under the system account.
Looks really like something is wrong with some permissions... Any idea what's going on here ?
Edit:
From what is been said in
https://serverfault.com/questions/185813/which-ad-permission-is-required-to-allow-impersonation-of-an-account/193717#193717
I checked the permission ofr impersonation in Local Policies -> User Rights Assignment. System is present, and for the sake of completeness I also added the computer account. Restarted. But with no luck, problem still there !
Ok, I finally got it. It seems that for security reason the System account can not initiate impersonation. The solution here was to change the account running the script, from system to a custom account. And then to allow impersonation for this account in security policies as said here: