M0rph77
Enthusiast
Enthusiast

Security context of scriptable task issue

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,

0 Kudos
1 Reply
tschoergez
Leadership
Leadership

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

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