Orchestrating the orchestrator: reaching out to the untrusted domain

Now that Microsoft is pushing the cloud as a new way of building and experiencing IT, SCORCH (I love this abbreviation btw!) is positioned as the bread-and-butter tool to simplify your datacenter-management along with the rest of the SC family.

While most SaaS environments aren’t hard to clamp in scorch’s grip, as they are usually contained within a single domain, what about IaaS or PaaS where there is much more isolation in place?

Before I go into further detail, I’ll summarize the topology of scorch:

source

 

– The management server is responsible for storing flows in the datastore and pushing tools or IP’s to action servers and clients (although they can be manually installed as well). It can also start flows on action servers when commanded to by either a client or the webconsole.

– The action server can be assigned workflows, which it then executes when commanded to by the management server. The action server only needs a connection to the datastore in order to function.

The caveat is that both the management- and action servers run under the usual service account. And unless you want to juggle around with credentials within your flows, you want to run the action-server under a credential that has localadmin-rights on the servers that exist in your flow-scope. Furthermore, the action-server uses its credentials to access the datastore.

These requirements don’t add up when the action-server resides on an untrusted domain. How can it reach it’s datastore, how can it be reached by the management-server if needed?

I asked myself (and google) the same question, and got these results:

A TechNet forum-topic

A Microsoft guide on how to manually deploy an action-server

 

This got me on my way to break through the barrier between my scorch-servers:

– In both the native and untrusted domain, create a service-account for the scorch action-server. These MUST be identical in both account name and password!

– Assign the remote account as localadmin on the action-server.

– On the datastore, assign the local service-account the DB_owner schema. Also, create a SQL login ‘eg Orchestrator with password ‘0rch3str@t3Th!s’ and assign it the DB_owner schema as well. This will be used later to register the remote action-server.

– Copy the following items from the scorch-management server to the future action-server:

OpalisIntegrationServer_ActionServer.msi from <Management Server installation location>\Components\Server\

OpalisIntegrationServer_FoundationObjects.msi from <Management Server installation location>\Components\Objects\

Any Integration Packs that need to be installed from <Management Server installation location>\Components\Objects\

– Install the components by using msiexec and the commandline:

Action Server
msiexec.exe /i “<location>\OpalisIntegrationServer_ActionServer.msi” /qn ALLUSERS=1 AS_USERNAME=<domain\account> AS_PASSWORD=<password>

Use the remote service account in the AS_USERNAME and AS_PASSWORD parameters.

Foundation Objects (base scorch flow-objects)
msiexec.exe /i “<location>\OpalisIntegrationServer_FoundationObjects.msi” /qn ALLUSERS=1

Any Integration Pack needed to execute flows
msiexec.exe /i “<location>\IntegrationPackInstallationPackage.msi” /qn ALLUSERS=1

 

– Point the action-server to the datastore
Now that the action-service is installed, you must point it to the datastore on the native domain. This is done by the database-configuration utility, which gets installed along with the action-service.

 


source

Point it to the SQL-server on the native domain, and use the SQL-login created earlier to connect and register to the database.

– Verify the action-service is running
If it’s running, all should be okay as it will only keep running if there is a connection with the datastore.

At this point when you open the deployment-manager on the management-server, the new action-server should be visible and usable!

source

 

You can now assign flows to the action-server and run them under the remote domain’s security-context, nice!

 

The magic (although lame) trick behind this method is that when the remote service-account accesses the datastore, which has an identical local account as owner, it forces a fallback from the regular Kerberos authentication to a failover protocol where credentials are matched by a hash based on account-name and password (like workgroup-authentication). As the accounts are identical, the authentication succeeds.

An alternative to this method is to program your flows with remote credentials and connect to the remote domain that way, but this requires a lot of flowdesign-overhead and isn’t as practical as having a ‘man behind enemy lines’.

Another cool part is that once the initial setup is complete (and the database-config tool supports parameters), you can design a workflow that will automate the deployment of remote action-servers. In essence, scorch can expand itself!

Although this method works, it is far from beautiful. I hope (and assume) that SCORCH 2012 will have more out-of-the box possibilities to support a workgroup/untrusted domain scenario.

But for now, let the orchestrating begin!

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Orchestrating the orchestrator: reaching out to the untrusted domain

  1. Quality articles or reviews is the main to invite the users to pay a visit the web site, that’s what this web page is providing.

  2. She scorched the ramp at an underwear fashion show, thanks to the Brazil butt lift workout
    program under Leandro Carvalho. It’s not the animal that matters,
    it’s where the meat comes from on that animal. Having more healthy cells
    and tissues will definitely improve your metabolism since it is your cells and tissues that metabolize your
    calories to fuel your bodily functions, after all.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s