Hello,
The following issue arrises;
I've got a powershell script that needs to bind to the vmware lab manager internal api with pre-supplied credentials.
I want the following to be automated;
1) to bind to the web service without manually adding credentials (through a powershell script)
2) to use the script from orchestrator
I've created a $credentials variable with a secure-string password from a encrypted text file.
When orchestrator runs the task, it uses the "SYSTEM" security context wich cannot read from the to secure string converted password file.
My Powershell Code:
to create the password file:
read-host -assecurestring | convertfrom-securestring | out-file password.txt (under a domain admin user security context)
fill $credential
$pass = cat password.txt | convertto-securestring
$credential = new-object -typename System.Management.Automation.PSCredential -argumentlist "<domain admin account>",$pass
create web service proxy
$server = "https://<server>/LabManager/SOAP/LabManagerInternal.asmx"
$proxy = New-WebServiceProxy -Uri $server -credential $credential
Symptoms and problem
Running the script manually under my domain admin account context the script works fine as intended.
When I run the script from a Orchestrator scriptable task; the powershell script returns following error:
"Convertto-SecureString : Key not valid for use in specified state.." etc..
The orchestrator instance of the powershell script, run under the SYSTEM account security context, cannot read the encrypted password file.
Questions:
1) Does Orchestrator indeed run tasks under the security context of the SYSTEM account?
2) Is it possible to run an Orchestrator task under a different security context?
3) Has anybody found another solution for a similar problem?
Thanks in advance,
Hi!
To your 3rd question: We had same probleme with an external 3rd-party-command which has to run in a different context.
Our (not satisfying) solution was to run the orchestrator service not with SYSTEM account, but with a user account (we have special administrative accounts for applications). But this is not officially supported by VMware (we had some support issues, not related to this, and it was never a problem).
We also have no problems with running orchestrator with a separate user account.
(discussed in this thread http://communities.vmware.com/thread/280865?tstart=50 )
Cheers,
Joerg