Security context of scriptable task issue


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.


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,

0 Kudos
1 Reply


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 )



www.vcoportal.de - Orchestrate. Your Cloud.
0 Kudos