Phone Number +1-202-802-9399 (US)

Thycotic is now Delinea!

The Lockdown

Thycotic’s Cyber Security Blog

vRA and vRO integration with Thycotic Secret Server

Written by Jordan True

December 22nd, 2015

Guest blog post by Scott Norris.

When working with vRA—formally vCAC and vRO—it is integration with third-party systems or devices that makes vRA and vRO so flexible. The magic sauce of this integration is vRealize Orchestrator (vRO). There are plugins available, and in cases where there is no suitable plugin, there are options available to make your own integration.

Today I will be showing you how to integrate with Thycotic’s Secret Server enterprise password management solution. Many of my enterprise customers utilize Secret Server to store and generate passwords as well as grant permissions and audit password access based on group membership, basically a big fancy password safe.

Secret Server has a SOAP API and allows us to integrate seamlessly with IaaS or PaaS deployments or even Password as a Service. The main calls being used are generating passwords, store passwords, retrieve passwords and delete passwords. Using this and tying into IaaS or PaaS deployments we can be sure every deployment has unique passwords and securely stored for the person who requested it. It can automatically generate and change the Root password for Linux boxes or the Administrator account on windows servers on deployment.

We can store the secret ID as mentioned in Extending vRA with ETCD posts, and grab the password pragmatically for day 2 actions without the end-user ever needing to know the password. I provide the workflows being used today for everyone to have a look at and try out, as well as a link to the YouTube video.

Workflows to SOAP Actions which will need to be replaced with your own operations are:

Add Secret Server Secret – SOAP Operation : AddSecret
Deactivate Secret Server Secret by ID – SOAP Operation: Deactivate Secret
Generate Secret Server Password – SOAP Operation: Generate Password
Get Secret Server Folder – SOAP Operation: FolderGet
Get Secret Server Secret by ID – SOAP Operation: GetSecretLegacy
Get Secret Server Secret Summary – SOAP Operation: SearchSecretsByFieldValue
Get Secret Server Templates – SOAP Operation: GetSecretTemplates

Lets get started:

1) Adding Secret Server as a SOAP host. depending on version there is 2 different URLs to use one for Windows authentication and one for local authentication. I recommend going with windows authentication as it doesn’t require token generation. Use the add SOAP host workflow and fill in the appropriate details




2) Now let’s take a quick look at the workflow. I won’t go through the creation of all these workflows as that would be way to long.
As you can see for from the below image. There are a number of smaller workflows that can be made into a larger parent workflow.


The request Secret Workflow is the main one that is called. The inputs are:

  • Server product – What the password is for
  • idVar – This is an ID generally I would use a PaaS ID or something deployment ID something that can be tracked and is unique
  • Username – This is the user name for the password
  • FolderPath – This is where you want the password stored
  • passwordTemplateName – Template used to generate password
  • SecretTemplateName – The template used to store the password
  • RoootfolderID – this is the folder ID of the root folder
  • ServerName – this is the server service this password is for
  • Domainname – domain name of the server or service.


Watch the video at the end of this post for more detail. The template is a Secret Server template. There are many out of the box but I created my own. As shown in the below image a template dictates the password requirements as well as the fields required or available to be entered.


3) Now running that workflow we enter all of the above like the image below and cross the old fingers.


As you can see there is a lot of logging. I do not recommend logging the password but in this case it’s to demo that it actually works.


Now let’s check Secret Server and see if its been stored.


4) Adding into Application Services is easy. vRO has a great API and we can call the workflow and supply the same inputs above, and can retrieve the outputs to supply back to the Service. script I used is similar to the one found at Defined by Software. Rolling that into a service and using it in blueprints is easy. From vRA7 we will be able to use the workflow natively in Application Services which will be known as Application Authoring, making this step even easier.




This allows other services to use the password generated, allowing for more security and unique passwords per deployments.


5) To remove the password from secret server we run the deactivate secret workflow which requires the secret ID.



All looks good! Other use case is to include this in ProvisionedMachine workflow stub to change the passwords for all local accounts on deployment.
Have a look, have a tinker, enjoy!


IT Security should be easy. We’ll show you how.

Try Secret Server and experience how FAST & EASY
IT security products can be.